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Začátek 


+ 
Uvodník 

Hello to all Speccy-fans! 

Je tomu již více než rok, co vyšlo první 
číslo obnoveného ZXM. A vyšlo pouze pět 
čísel z původně plánovaných sedmi, což je 
alarmující, ano, bohužel je tu zcela neplá- 
novaný skluz. Naštěstí je teď ZXM vydáván 
za podpory firmy CONOUEST, což je velmi 
pozitivní, neboť se rapidně snížily náklady, 
tudíž bychom mohli, tedy pokud bude do- 
statek článků, vydávat ZXM častěji. A abys- 
te nemuseli číst články stále od těch sa- 
mých autorů, musíte posílat své vlastní, bez 
příspěvků to prostě nejde. 

Co se týče obce předplatitelské, tak ta 
se nepatrně s každým vydaným číslem zvět- 
Šuje, většina z Vás má však předplaceno 
následující číslo nebo dvě, proto Vás pro- 
sím, abyste po vyjití příštího čísla poslali 
předplatné na dalších šest popřípadě na 
další tři výtisky. Samozřejmě nic není zadar- 
mo, a tak pokud bude ZXM dál vycházet, 

a to bude, tak Vám nepředplacená čísla ne- 
přijdou. 

Doufám, že se Vám tento ZXM bude líbit 
stejně, ne-li více, jak ty předešlé, že se Vám 
ze článků o packování nezapackuje mozek, 
a že nezapackujete Speccy pod skříň a ne- 
zdrhnete k PeCím. 

Přeji Vám hezký zbytek prázdnin a uvidí- 
me se na DOXYCONUu (viz vedlejší stránka). 


Matěj Kryndler - šéfredaktor 


Tak tohle číslo na mě Matěj přímo neho- 
dil část úvodníku, ale ten svůj dodal moc 
krátký, tak aby tu nebylo prázdno, zas pár 
slov ode mě. 

V tomto čísle je na rozdíl od toho minulé- 
ho méně recenzí na hry a naopak je více 
technické. Když jsem poprvé viděl Gamův 
článek o pakování a pakerech, zhrozil jsem 
se. Délka přes 30 kB čistého textu... Ale roz- 
dělovat se mi ho nechtělo, neboť si ještě 
živě pamatuji svou nechuť k „rozděleným“ 
článkům. Prostě to není ono. Něco jiného 
jsou originální seriály přímo od autorů 
(CP/M, seriál o D40). A protože Gamův člá- 
nek „sežral“ 5 a půl strany, už na hry moc 
nezbylo :-). Pokud někoho z vás metody kom- 
prese vůbec nezajímají, kupte si příští ZX 
Magazín. Gama dodal podobné (i když ne 
tak dlouhé) články o ruských klonech spekt- 
ra a assemblerech (editorech a překlada- 
čích) pro ZXS. Novinky samozrejmě chybět 
nebudou a i na recenze her snad vyjde mís- 
to. Co jsem tak prohlížel, co všechno mám 
na disku připravené k otištění, ke komprimo- 
vání se ještě vrátíme, o hardware se tu taky 
něco najde. Chystám s PVL podrobnější člá- 
neček o HDD a CD-ROM (nejen připojení, ale 
snad kompletní „programming tutorial“ -). 

A málem bych zapoměl. VELIKÉ DÍKY 
Tomášovi Hauerlandovi (TDM) za fotku na 
obálku, kterou sem bez jeho svolení použil. 
Doufám, že mi za to na DoxyConu neutrhne 
hlavu... :). 

Lubomír Bláha - Tritolsoft 
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Pozvánka 


DoxyCon "99 


Jelikož jsem z Inter(fer)netu stáhnul tuhle 
hezkou (no, byl to jpeg) mapu, která se akorát 
pěkně vešla na stránku, přikládám i oficiální 
pozvánku a informace od pořadatelů. 

Tritolsoft 
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Team E.S.A. si Tě dovoluje pozvat na 
akci „Doxycon '99“, která se koná jak byla 
ohlášena, tedy 23. až 25. 7. 1999, v kul- 
turním středisku „Pension Starý Mlýn“, 
vedle restaurace „Sklípek“ (u potoka) ve 
STARÝCH SPLAVECH (cca 2 km od Doks - 
na druhém břehu Máchova Jezera). 


Jak se tam dostat: 

Na mapě jsou vyznačeny možné trasy: 

1) ČERVENĚ (tady je to ta tmavší - 
pozn. tnt) pokud přijedete vlakem - Jeďte 
vlakem do stanice „Staré Splavy“ a odtud 
jděte po hlavní ulici (ul. Dalibora z Myšlína) 
až k místu konání (cca 300 m od nádraží). 


POZOR! Spěšné vlaky ve stanici Staré 
Splavy zastavují pouze ve směru od Mladé 
Boleslavi, proto pokud tímto chcete jet, vy- 
stupte již ve stanici DOKSY a zde počkejte 
na místní spoj do Starých Splavů nebo jeď- 
te autobusem, který má zastávku nad ná- 
dražím, viz. mapa. 

Nebo můžete jít po svých podél Mácho- 
va jezera (asi 1,5 km), když přejdete most 
nad nádražím a poté se dáte vlevo. Ve St. 
Splavech vyjdete v ulici Jarmilina stezka). 





2) ZELENĚ (zde logicky ta světlejší - 
pozn. tnt), když přijedete autobusem - Vy- 
stupte na zastávce „Staré Splavy“ a jděte 
dále do města. Asi 100 m odtud je vlaková 
zastávka a železniční přejezd a odtud již i 
stejně jako v bodě 1. 4 ee 

3) AUTEM (nevyznačeno) - Na křižovatce směr 8 ez 
u Doks neodbočujte (nevjíždějte) do Doks, Česká Lipa“ 
ale jeďte směrem Česká Lípa. Asi po 2 km ' 
je zde viditelná odbočka vpravo do Starých 
Splavů. ' Ne 


Je zde problém s přespaním, proto si i „7 R 
účastníci budou muset zajistit nocleh sami. = 


Kdo nechce, může samozřejmě přenocovat 


(probdět noci) na místě, ovšem bez zbyteč- F p 
ného hluku. muž zast Dokey-5pot DOKSY 
== u“ 
Účastnický poplatek se nemění, tedy a : 
100 Kč/osoba. Peníze slouží k zaplacení ky th ll JE: = 
č : mim Eryrí "bi L E: mém 
nájmu z poskytnutých prostor. i + = É č 
Vo 3 | v 
Těšíme se na Vás! č, pa E, mě 
Team E.S.A. = zn E k mě" X 
| ť m E eh x 
VŽ Tok 5 íme E 
Jé, zbyl mi tady ještě takovej cancourek... o dí € “ 4 = ee 
DoxyCon "98 byl super a letos to určitě u ne ve i P 3 
bude ještě lepší. Přijede mnoho známých | Au má TDC za 72h R 
osobností jak z ČR tak zahraničí, takže po- „E -Met P M 
kud chcete být „IN“ a ne „OUT“, určitě při- kyj : u, 
jeďte. : „E i E 
Tritolsoft | ěr Praha Hedé Boal K a 
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NoWinky 


Když jsem v předminulém čísle nadával, 
že nemám ani demoverzi SMAGLYho 3, ne- 
tušil jsem, že se mi asi měsíc po vydání se- 
jdou dema hned dvě, první pro 48 kB s oši- 
zenou grafikou a jednou krátkou úrovní, 

a druhá only 128 kB se špičkovým intrem - 
viz obrázek, skvělou grafikou i ozvučením. 





Jednou z mála novinek bez přiloženého 
obrázku bude plná verze ICE CLIMBERa, ze 
kterého jste mohli screenshot vidět v před- 
minulém čísle (alespoň si to myslím). 


Mezi nejaktivnější skupiny v bývalém 
SSSR patří bezesporu grupa FATALITY 
(http://ftl.da.ru), která se, po dokončení lo- 
gickoakční hry PUSSY - The Titanic Story, 
rozhodla předělat z Amigy pařbu FANTASTIC 
DIZZY. 
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Zcela neznámá MULTYPLEX GROUP pře- 
dělává WORMS. V plné verzi bude možno 
hrát proti počítači, budete moci použít 










die] 
a ROSE 
NE 
8 Ra U 
E 


T 





všechny zbraně, a přibude ozvučení. (Menu 
je na Spectru v interlace módu, ovšem v ča- 
sopise to není vidět :-) 


Pro příznivce dungeonů tu máme lahůd- 
ku COURSE OF XEEN, od které bohužel ne- 
známe ani autora. 





ALLIANCE TEAM připravuje hru MEGA- 
Bé" 6*M - předělávku Dynablastera, která 
bude zabírat celou BETAdisketu, samozřej- 
mostí je ozvučení pro AY a General SOUND, 
multikolorové animace, bonus levely a další 
vychytávky. 





MANIC MINER TECHNOLOGIES (pravděpo- 
dobně z ANGLIE) přinesli na obrazovky ZX 
Specter další pokračování dobrodružství hor- 
níka Willyho, tentokráte pod názvem EUGE- 
NE - LORD OF THE BATHROOM. Ve hře na- 
leznete vylepšenou grafiku, vydařené levely 
na motivy známých her, změněnou hudbu 
a další. Hra pojede i na 48kB Spectru. 


MASTER HOME COMPUTERS GROUP při- 
pravuje hru WORM, jedná se o klasickou „se- 
žíračku“ čísel, plusů, mínusů a v plné verzi 
možná i dalších pochoutek, výjimečný je na 
této hře pohyb červa, neboť nezatáčí o 90 


stupňů, ale plynule po kruhové trajektorii. 





A pro zaryté počítačové sportovce máme 
eso v rukávu - hru HEADBALL od firmy ZX- 
MASTERS. Jedná se v podstatě o předěláv- 
ku stařičkého ARCADE VOLLEYBALLu z Pe- 
Ce, provedení je ovšem na vysoké úrovni. 


JEHO = BA:HA  KOMIBATEPA 





BSOFT z Běloruského města Grodno pře- 
tvořil a vylepšil PéCéčkářskou hru M$ HE- 
ARTS. Jeho výtvor se jmenuje KING a pro 
hráče karet bude asi přínosem. 
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DEECKOBRUZ a RUFF ze skupiny AVA- 
LON přinášejí hru KICK DA GAGA, prazvlášt- 
ní akční hra pro dva playery nebo jednoho 
a počítač. Cílem je sebrat všechnu energii 
svému soupeři pomocí nárazů. u 








Recenze 


Three „Weeks“ in paradise 128 


+GAMA 


Ano, je to tak. Slavná hra Dave Perryho 
ještě z dob, kdy psal pro firmu Microgen 
(slavný rok 1986, kdy vznikala ta nejlepší 
Spectrácká klasika), má už svou 128 verzi 
(a to oficiální, žádný hloupý remix nebo tak 
něco). Nevím, jestli se dá někde normálně 
sehnat, mně to trvalo dost dlouho a ještě 
jsem ji dostal jenom jako .Z80 snap, dva 
dny jsem se nad ním trápil, hlavně nad zá- 
sobníkem a přesilou pushů a popů, než 
jsem rozIdirovanou hru dal zase do kupy 
a zapakoval, ale povedlo se. Aspoň že tak. 
Znovu říkám, jinak než ve snapu se mi hru 
nepodařilo nikde najít. Proč 128 verze? Čím 
se liší od té 48ičkové, kterou všichni tak 
dobře známe a na kterou vycházejí návody 
v každém Fifu (a dokonce i v jednom star- 


ším ZX Magazínu)? No tak nepočítám-li ta- 
kové drobnosti, že úvodní obrázek se uklá- 
dá do druhé VRAMky, že ta slavná úvodní 
hudba, kterou všichni tak vesele vykrádají, 
hraje na AY (a zní to moc dobře), je tu ještě 
spousta věcí. Bohužel, já nemohu přesně 
posoudit, co ve 128 verzi proti 48ičkové je 
navíc, protože 48 verzi jsem nikdy neměl 
(když totiž víte, že existuje 128, tak už se se 
48 nikdy nespokojíte, zvlášť když víte, že 
128 verze je lepší). Zkusil jsem ji ale hrát 
podle návodů v ZXM a zažil jsem několik 
překvapení. Podle něj by v místnosti u vos 
měla být tupá sekera. Ne, je tam plazmový 
deštník. Projdeme-li do moře a z podmoř- 
ské jeskyně (z té se scrolltextem „Where is 
Pete?“) odejdeme DOLEVA (plotem se dá 
projít se štípačkami), stále doleva podzem- 
ním zbrojním komplexem či co to je, za plaz- 
movou stěnou teprve leží sekera (tou stě- 
nou se dá projít s deštníkem). To by byl je- 


den rozdíl - ten vojenský komplex ani nebyl 
na žádné mapě, pokud se pamatuji... Rozdíl 
druhý byl v tom, jak šaman nebo bůh deště 
či co je to za postavu, reagoval na horký po- 
pel. Nebo ne on, ale ten mrak. Začal hrlit 
blesky, ale z místa se nehnul. Což by se 
podle návodu hnout měl. Takže pokud se 
128 verze podle starých 48čkových návodů 
nedá hrát, znamená to, že tu skutečně jsou 
věci navíc (mohu potvrdit, v každé paměťo- 
vé stránce je něco, co asi bude mít nějaký 
význam). No dobře. Ti, co tvrdili, že Three 
Weeks in paradise není špatná hra pro 
48ku by si honem měli 128 verzi opatřit. Až 
bude čas, budu se o ní snažit zjistit víc, ale 
rozhodně by nikomu neměla chybět! Už je- 
nom proto, že hráč se na osvědčený návod 
nemůže zcela spolehnout a musí hledat 

a zkoušet sám. Doufám, že rozdílů bude 
ještě víc (nepohrdl bych nějakým animova- 
ným a ozvučeným závěrečným outrem). 
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Vítejte u pokračování skvělé logické hry 
BOOVIE. Tentokrát (jak jste jistě postřehli) ji 
nemá na svědomí KVL, což jí ale vůbec neu- 
bírá na kráse. V tomto pokračování ubylo 
pár věcí, ale taky pár (tuším, že dvě) věcí 
přibylo. Boovie má na pomoc dva předmě- 
ty - magnet a plo... teda bombu. Magnet 
umí přitahovat kvádry (jsou totiž z magne- 
ticky bohaté horniny); bomba zas likviduje 
zelený porost, který občas překáží v cestě. 
Pokud nevíte o co ve hře jde, pak vězte, že 
„jenom“ o dostrkání bílého kvádru na plo- 








2 48 © 1998 E.S.A. Team 


Johny X 


šinku. Zní to jednoduše, ale člověk míní, re- 
alita mění... 

Teď k technickému zpracování. Grafika 
je jednoduše nádherná, nevím, kolik jí je 
Z původní hry, ale animace samotné posta- 
vičky je super, pokud necháte chvíli Boovie- 
ho bez pohybu, začne se krásně nudit. Po 
pravdě řečeno, nejvíc z grafiky se mi líbí ob- 





rázek, který se objeví po projevení gravitace 
na kvádr, který vlivem volného pádu změní 
vlastní energii potencionální na energii ki- 
netickou, z dopadem měnící se na energii 
deformační, což se patřičně projeví i na 
hlavní postavě (ovšem pokud se Boovie 
snaží padající kvádr zastavit vlastní hlavou 
nebo jinou částí těla). Vzhledem k brutalitě, 
kterou obrázek obsahuje a nemožnosti zá- 
kazu čtení ZXM před 22-tou hodinou, musí- 
te si hru opatřit. Beeper se projeví pouze při 
vkládání hesla, AY-čko hraje jednu ze tří hu- 


deb, které má na svědomí FACTOR 6, ze 
kterých si každý vybere tu svou. Mě osobně 
se líbí hudba č.3, ale to je otázka názoru. 
Ovládání je popsáno ve hře samotné, po- 
kud vím, nepodporuje žádnou veselou páku 
(joystick). Před hrou je ještě intro, ve kterém 
se dozvíme, že hra je věnována BONNY B. 
k jejím narozeninám a další méně či více 
důležité informace. No, nakonec abych je- 
nom nechválil, jediné, co mi ve hře vadí, je 
neustálé vkládání hesla kola, což je ale ma- 
linká skvrnka na obrovském slunci. Jinak 
řečeno, hra je výborná, má něco přes 40 le- 
velů (tuším) a vydrží vám dlouho. Pokud ješ- 
tě nemáte důvod hru si opatřit, pořiďte si ji 
už jenom kvůli vinikající hudbě a výše zmí- 
něnému brutálnímu obrázku. 


p E 
Wii Ti de bí 





Pokud bych měl ohodnotit, hra by dosta- 
la 8/10 bodů. u 


(Jelikož ten „gravitační“ obrázek je fakt 
super, neudržel jsem se a dal ho sem. To 
ovšem neznamená, že byste si hru neměli 
pořídit - pozn. tnt.) 
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Programování 


KomprimAce dat je výhodný způsob, jak ušetřit paměť nebo záznamovou kapacitu média. 
Nyní vám nabízíme možnost poodhalit její podstatu. 


Komprimuji, kmrmy, krj, kj, k, ... 


Petr Žabenský 


O komprimÁci jste již určitě někde četli. 
Něco již vyšlo FIFU, něco i v jiných časopisech, 
které se už věnují jenom PeCím. Pokaždé, 
když někdo píše o komprimAci, tak mluví 
o jednoduché komprimaAci. Ta je založena na 
tom, že se zaměříme na posloupnosti stej- 
ných znaků, nebo si zaznamenáváme polohu 
nenulových bytů. Všechny tyto algoritmy jsou 
jednoduché a hlavně rychlé. Jejich nevýhodou 
však je, že se klidně může stát, že soubor po 
komprimAci může být až dvakrát větší, než 
před ní. A pravděpodobnost této situace je 
u některých algoritmů značně vysoká. Kom- 
primační programy využívající takovéto meto- 
dy se dají využít spíše ke kompresi obrázků 
a některých speciálních dat, pro které dosa- 
hují nejlepší účinnosti. 

My si dneska řekneme o metodě, která je 
velice účinná obecně. Používá se ke komprim- 
Aci souborů větších než asi 2 kB (proč, to si vy- 
světlíme později). Ta metoda se nazývá Huff- 
manův kód. Myšlenka kódování (nezaměňujte 
s jiným kódováním, my budeme komprimovat!) 
je založena na podobném principu jako Morse- 
ova abeceda. Když si ji totiž položíte před sebe, 
zjistíte, že písmena, která se používají nejčastě- 
ji, mají i nejkratší kód. A tuto myšlenku se po- 
kusíme aplikovat. V „Morseovce“ se používají 
pouze dva znaky: čárka a tečka. Když nahradí- 
me tečky jedničkou a čárky nulou, už bychom 
se dopracovali k nějakému výsledku. Princip je 
tedy takový, že posloupnost bytů zakódujeme 
do posloupnosti bitů, kde vynecháme nepo- 
třebné bity. Ale to ještě není vše. Musíme si ješ- 
tě určit nějakou zarážku, která nám při dekom- 
presi určí, kdy končí jedno písmeno a začíná 
druhé. To však není tak jednoduché, protože 
mimo 1 a 0 už nám v binární aritmetice nic ne- 
zbývá. Musíme si totiž uvědomit, že když zkom- 
primujeme data a potom je zase odkomprimu- 
jeme, musíme dostat úplně shodné soubory. 
Jak si tedy vytvořit takovou zarážku? 
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Nebudu vás dlouho napínat a rovnou vám 
prozradím, že tento problém vyřešíme pomocí 
tzv. binárního stromu. Nejdříve si však tento 
pojem objasněme. Pokud jste již programovali 
v PASCALu a používali jste DDS (Dynamické 
Datové Struktury), tak jste se s ním již určitě 
setkali. Jeho název vychází z podobnosti se 
skutečným stromem. Jeho větve jsou spoje- 
ním mezi jednotlivými uzly, ve kterých je za- 
znamenána informace. Každý uzel obsahuje 
údaj (u nás to bude znak a číslo), odkaz na 


předchozí (otcovský) uzel a na následující 
(dceřinné) uzly. Binární se mu říká proto, pro- 
tože následující uzly jsou pouze dva: levý 

a pravý. Proč jenom dva? Protože máme jen 
dva symboly: O a 1. A takovýto strom je právě 
vhodný pro naši potřebu (viz. obr.1) 

Jak tedy pracuje Huffmanovo kódování? 
Předpokládá se dvojí průchod souborem. Nej- 
dříve je nutné sestavit tabulku četnosti jednot- 
livých znaků v souboru a z této tabulky vytvořit 
binární strom. V druhém průchodu už probíhá 
samotné kódování. Předveďme si to na příkla- 
du. Máme následující text: VENKU JE HEZKY. 

Tabulka četnosti bude: V (1x), E (3x), N 
(1x), K (2x), U (1x), mezera (2x), J (1x), H 
(1x), Z (1x), tečka (1x). A nyní si sestavíme bi- 
nární strom. Napíšeme si do řádku všechny 
znaky, které jsou obsaženy v textu právě jed- 
nou. Jsou to: V, N, U, J, H, Z, Y. Nad každý znak 
si napíšeme do kroužku jedničku (počet vý- 
skytů). Nyní znaky pospojujeme do dvojic, tak 
vytvoříme o řádek výš pro každé dva znaky 
otcovský uzel (ten už ale nebude obsahovat 
znak, znaky jsou totiž jen v koncových uzlech), 
k němuž napíšeme součet četností (tedy 2). 
Jelikož bylo v prvním řádku 8 uzlů, vzniknou 
nám 4 otcovské uzly. Do téhož řádku už může- 
me přidat i uzly se znaky, jejichž četnost je 
dvě. | tyto uzly spárujeme. Ve třetím řádku zís- 
káme 3 uzly, ke kterým přidáme E se třemi vý- 
skyty. V následujícím řádku už budou uzly se 
součty výskytů 7 a 8. Když je spojíme, získá- 
me kořen stromu, odkud budeme vycházet při 
dekódovaní. Jeho součet četností je stejný 
jako počet znaků v souboru. Vytvořený binární 
strom je na obrázku 2. 


ela. A 


Nyní si popíšeme vlastní postup při kódová- 
ní a dekódování. Pokud budeme kódovat, bu- 
deme procházet strom od umístění znaku ke 
kořeni. Pokud vstupujeme do otcovského uzlu 
zleva, zaznamenáme si 0, pokud zprava, píše- 
me si 1. Po vstuu do kořene musíme zapsat 
získanou posloupnost do souboru obráceně. 
Najděme si tedy kód písmen E aY. Písmeno E 
bude znamenat cestu levá-pravá, tedy 01, ob- 
ráceně 10. Je tedy kódováno do dvou bitů. Pís- 
meno Y je levá-pravá-pravá-pravá, tedy 0111, 
pozpátku 1110. Je tedy kódováno 4-mi bity. 
Celá věta bude tedy zakódována takto: 
0100-10-0101-001-0110-000-0111-10- 
000-1100-10-1101-001-1110-1111 
(V-E-N-K-U- -J-E- -H-E-Z-K-Y-.) 

Celá věta je zakódována do necelých 7 
bytů, přitom normálně by zabrala 15 bytů! 
Dekódování je jednoduché. Začínáme u ko- 


řene. Podle pravidla O vlevo, 1 vpravo se no- 
říme hlouběji, až se dostaneme do koncové- 
ho uzlu. Následující bit už je začátek kódu ji- 
ného znaku. 

Pro názornost si ještě uvedeme další pří- 
klad. Máme tyto četnosti: A (1x), B (2x), C (3x), 
D (4x), E (5x), F (6x), G (7x), H (8x), 1 (9x), J 
(10x). Výsledný strom najdete na obrázku 3. 
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Ještě jednu velice důležitou věc! Pokud bu- 
dete kódovat nějaký soubor tímto způsobem, 
nesmíte zapomenout někde si zaznamenat 
strukturu stromu, protože bez něj soubor ne- 
lze rozkódovat. Nejlepší je, když si ho uložíte 
na začátek souboru a od dat si ho oddělíte 
nějakou značkou. Před dekomprimací si ho 
pouze „natáhnete“ a můžete pracovat. 

A jaká je efektivita tohoto algoritmu? Je 
vhodné ho používat ke komprimaci souborů 
větších než 2 kB, protože tak veliký je asi bi- 
nární strom (záleží na struktuře, kterou zvolí- 
te). Pokud byste dosáhli nulové komprese (tj. 
žádné úspory), tak vám velikost souboru na- 
roste maximálně o ty 2 kB, nikdy ne o více. Ta- 
ková situace může nastat tehdy, když se 
všechny znaky vyskytují ve stejném počtu a je 
jich v souboru obsaženo všech 256. Schválně 
si zkuste napsat všech 256 znaků vedle sebe 
a začněte spojovat vždy dva sousední, potom 
spojte vždy dva takto vzniklé uzly atd. až se 
dostanete k jednomu uzlu, který už není s čím 
spojit, a to je kořen. Když si teď spočítáte 
„vrstvy“, zjistíte, že jich je právě 8. Proč? Zkus- 
te si to spojit s binární aritmetikou a s binární 
reprezentací každého znaku. Ještě vás nic ne- 
napadá? Tak ještě chvíli přemýšlejte. 

Když tedy zhodnotíte všechny uvedené in- 
formace, zjistíte, že algoritmus Huffmanova 
kódování je vysoce efektivní. Můžeme s ním 
dosáhnout vysoké komprese dat. S tímto al- 
goritmem by se dala provádět i vícenásobná 
komprese a komprimovat tak dlouho, až se 
dosteneme do stavu, že výsledný soubor je 
větší než původní (taková malá rekurze). 

Tento algoritmus nemusíme nutně použít 
pouze pro kompresi. Velice výhodně ho lze vy- 
užít například pro zakódování programu, aby 
nám ho nikdo nenaboural. To už však záleží 
jen na vaší fantazii. 

Samozřejmě, že popsaný algoritmus není 
ještě ten zcela nejlepší. Existuje několik dal- 
ších, které jsou ještě efektivnější než tento, 
jako např. aritmetická komprese, vylepšený 
Huffmanův kód atd. u 





+GAMA 


Úvodní blábol 


Pokud se vám název tohoto sloupku ne- 
zamlouvá, máte smůlu. Vypůjčil jsem si ho 
ze starších ZXM, kde vycházel na pokračo- 
vání seriál Crackeři a crackování od JSH. 

A o čemže to bude řeč? To neuhodnete. Já 
vám to ovšem prozradím. Bude řeč o packo- 
vání a samozřejmě se speciálně budeme 
bavit o packování na Spectru. Basta. Kom- 
primAce se dělí na ztrátovou a neztrátovou. 
Ztrátová se s oblibou používá na PeCi 
(haha, dobře jim tak), neztrátová je potom 
jediná z těchto dvou, kterou je možno pou- 
žít i na Spectru. Ztrátovou totiž nelze použít 
snad ani na obrázky. Tedy šla by, ale pak 
samozřejmě o obrázek přijdete. Na PeCi 
jsou na pomrvené obrázky zvyklí a nějaké 
ztrátové JPeGy je už z míry nevyvedou. Ne- 
ztrátová komprimAce se potom dělí na sy- 
metrickou a asymetrickou, a to podle časo- 
vé náročnosti packu a depacku. Pokud 
pack trvá stejně dlouho jako depack, je 
komprese symetrická. Pokud je depack ďá- 
belsky rychlý a pack trvá déle, je komprese 
asymetrická. Pakliže pack proběhne blesko- 
vě a depack trvá dlouho, nakopejte autora 
do prdele (příklady z praxe: MrPack, Pack- 
Maker). 

Komprese se ještě obecně dělí na pozi- 
tivní a negativní, negativní je taková, při 
které se data nesmrsknou, ale nafouknou. 
Nemusí to ovšem záviset na metodě, někdy 
to visí i na datech. Však o tom ještě bude 
pokec. 

Nezapomeňte ale, že ta úplně nejlepší 
komprese je data smazat. Cokoliv naprosto 
nutně nepotřebujem, smažme. Je-li nějaká 
hra prostě blbost, nemá cenu ji na disku 
nechávat. To je asi největší komprimační 
moudro. 


Kde jsem vzal tu drzost 


Ptáte se asi, proč o pakování píše nějaký 
blbý +GAMA. Já sám nejsem žádný teoretik 
oboru, spíše empirik a zkoušeč. Jak to za- 
čalo, nevím, ale prostě jsem se začal o pa- 
kátory zajímat, na počátku byla prostá tou- 
ha zjistit, který je ten TOP ONE, ten THE 
BEST, abych ho mohl používat a ostatní 
abych mohl s klidem zahodit. | počal jsem 
pakovat a pakovat různá data různými kom- 
binacemi packerů. Protože mi ale vycházela 
moc podivná čísla, začal jsem se v packe- 
rech šťourat víc. Ještě předtím ale přišel 
Matsoft s nehorázným požadavkem, abych 
napsal packer, který by mohl pakovat strán- 
ky 128ky, tedy aby depakoval jinam, než se 
blok nahrál. To jsme ovšem ani jeden netu- 
šili možnosti CHARPRESSu (tedy TOMpacke- 


Packefi a 


ru). Tak tedy vznikl perfektní, ale nikoliv 
účinný, packer Horatius. Přiznám se, ta 
rutina není ode mne, přinesl mi ji Matsoft 

a dnes už vím, že to byl nějaký shrink (RLE 
metoda) od Busysoftu, já jsem spáchal je- 
nom prostředí a ovládání, rutinku jsem sa- 
mozřejmě upravil tak, aby byla relokovatel- 
ná a podobně. Upozorňuji, že relokovat neu- 
mí ani CHAR. Ale měl jsem radši vyvinout 
nějakou svou metodu, ta Busyho rutina od 
Matsofta byla fakt debilní. Další peckou byl 
textový packer Tolkien, který se mi dostal 
do rukou a nemohl jsem přijít na to, jak ho 
ovládat. První, co mne napadlo, bylo napsat 
packer vlastní, bohužel jsem asi dvě nebo 
tři věci moc nedomyslel a tak nepakuje tak 
účinně, jak by mohl. Horší šok byl, když 
jsem Tolkiena konečně prokoukl a zjistil 
jsem, jak ty tři drobnosti řeší George K., 
škoda, byl jsem dost blízko... Horatius i Cae- 
sar jsou na ftp://sorry.vse.cz/pub/speccy, 
spíš jen pro zajímavost, normálně použitel- 
né asi nejsou. 

Když už jsem se ale o packery zajímal, 
proškolil mne důkladně Zilog, který je sku- 
tečně odborník na věc (škoda, že tuhle slá- 
taninu nepíše on, autor packeru, který 
trumfne i ruský multimetodový DSO 4...). 
Hodil bych sem jeho emaily s popisem jeho 
packeru, ale smazal jsem je, musíte se spo- 
kojit s vysvětlením mým. 





Packery se kdysi hodlal zabývat i PVL, 
nepříliš známý, ale neuvěřitelně schopný 
spectrista. Když jsem se ho ptal, proč snahy 
zanechal, odpověděl, že si napsal nějaký 
packer na obrázky, samozřejmě ne jen oby- 
čejný shrink, ale důkladnou implozi. Packer 
zkracoval obrázek přímo na obrazovce, aby 
bylo vidět, jak se to hezky pakuje. No pak to 
PVL spustil. A ono to zkracovalo, zkracova- 
lo, trvalo to už asi dvě a půl hodiny a pořád 
to šlo ještě zkrátit... a PVL se naštval, pro- 
hlásil, že to nefunguje, a nechal toho. 


Co je lepší packovat 


Pokud se divíte, že je taky možné být tak 
blbý a nevědět, že packovat se dá všechno, 


Programování 


Dackování 


uklidněte se. Tenhle poněkud zavádějící 
nadpis měl nadhodit asi následující pro- 
blém: Pokud si data zaarchivuji (ARJ, RAR, 
ZIP na PeCi), jsou sice smrsklá, ale nepouži- 
telná. Při použití se musí na disku rozpako- 
vat a žerou místo, které jsem chtěl původně 
packem ušetřit. Pak je taky možnost spá- 
chat samorozbalovací kód, který se neroz- 
pakuje rozpakovat až po natažení do pamě- 
ti (PKLITE na PeCi, většina Spectráckých 
packerů). To je samozřejmě řešení daleko 
výhodnější, i když se pak nemůžete v bloku 
svobodně šťourat, hledat texty a tak, musí- 
te ho rozbalit (a dobře zapakovaná hra je 
tak celkem slušně chráněna proti cracke- 
rům, pokud tedy nepoužívají SNAP). Zabale- 
ný soubor se taky zaarchivováním moc ne- 
smrskne, mnohdy naopak, viz třeba pro- 
blém s JPeGy na Peci. 

Pokud už říkáte, že nás se to netýká, 
pak je to tím, že na Spectru existuje takové 
množství diskových systémů, až to použití 
archiverů brání. Tudíž jediné skutečné ar- 
chivery, které jsem pro Spectrum viděl, po- 
cházely z Ruska a byly BETASHIT only. A při- 
tom nejsou nezajímavé. Za pozornost stojí 
hlavně LZ Compress, který má opravdu 
nádherné uživatelské prostředí ovládané 
šipkou (kdyby alespoň nepodporoval tu de- 
bilní ruskou myš a použil místo ní A-Mouse), 
a ZX Zip, bohužel jsem neměl možnost ově- 
řit jeho kompatibilitu se ZIPem PeCoidním 
(ale asi to bude jen shoda názvu). 

Ono abych byl přesnější, platformově zá- 
vislé jsou i „obyčejné“ Ruské packery, větši- 
nou vyžadující betu. Jen abych vyjmenoval 
ty nejrozšířenější: LZSS (nelíbil se mi), MS 
Pack (Rusové si ho velmi libují, vypadá hez- 
ky a nemá špatné výsledky), Hrust (často 
trumfne MS Packa), DSO 4 (DSO znamená 
Data SOueezer, pochází od Code Busters) 
...a to by mohlo stačit. Jak jsem už hlásal, 
žádný z těchto se na Zilogův packer nehra- 
be (sám Zilog má kontakt na autora Hrustu 
a získal od něj Hrust II s basicovým interfa- 
cem, aby ho mohl ozkoušet i bez Bety). Pac- 
kery rozšířené po Čechách snad vyjmenová- 
vat nemusím. 


RLE, značkový bajt 
a bit (SHRINK!) 


Předem se přiznám, nemám rád nic, co 
smrdí bitovou kompresí. Držím se hezky na 
pevné půdě celých bajtů. I když ty bajty ne- 
celé přijdou na přetřes rovněž. Ukážu vám 
ale, že v RLE ty bity svůj význam mají. Co 
je RLE? Run Length Encoding! To jste 
z toho chytří... Já tomu ovšem říkám 
shrink. Metoda je to neztrátová, jak jinak, 
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symetrická a obvykle ukrutně rychlá, a to 
za cenu nepříliš spackaných dat. Ovšem 
výsledek je na datech hodně závislý. Ukaž- 
me si teď ten značkový bajt. Struktura dat 
pak vypadá nějak takhle: Normální nespa- 
kovaná data... pak značkový bajt. To je 
bajt, který se jinak v bloku dat nevyskytu- 
je, nebo se na tento účel používá bajt nej- 
méně se v bloku vyskytující (to používá Ho- 
ratius), či je daný nějak fixně a pak je důle- 
žitá další struktura dat (pakující kopírák 
Gargantua). Po značkovém bajtu se ukáže, 
co a kolikrát se opakuje. Celkem tři bajty. 
Pak následují další nespakovaná data. 
Otázka je, jak to vyřešit, když se v bloku 
vyskytuje značkový bajt a je osamocený, 
tedy to není skupina bajtů, která by se 
dala spakovat. Emulátor Z80 na pakování 
snapů používá značkový dvojbajt ED ED 
xx yy, kde xx je kolikrát a yy je co, když je 

v bloku potom jenom jedno *ED, bere se 
jako nespakované. Dvě ED za sebou se 
spakují jako +ED ED 02 ED. Takže na 
spakovaná data se spotřebují ne dva, ale 
hned čtyři bajty. Tam už zbývá jen ošetřit 
situaci třeba ED 00 00 00 00 00 00. Na- 
bídlo by se spakovat to jako *ED (nespako- 
vaná data) *ED ED (značka) 06 00, ale po- 
čítač by to pak bral jako +ED ED (značka) 
+EDkrát 06, 00. Proto se při pakování ne- 
smí bajt za singl +ED zahrnout do bloku: 
FED +00 FED ED 05 00. Universumův ko- 
pírák Gargantua pro rychlé pakování bě- 
hem kopírování používá kvůli rychlosti rov- 
něž shrink. Jako značku používá bajt 127, 
kde se vyskytuje 127ka jako singl, spakuje 
ji tak, že 127ka se opakuje 1x. Tedy prod- 
loužení z jednoho bytu na 3. Zkuste kopíro- 
vat blok ze samých 127ček. Bude spako- 
ván na trojnásobek původní délky! V pří- 
padě jiného bajtu by se vám ale každých 

až 126 stejných bajtů smrsklo na pouhé tři. 
Tož tu vidíte, jak záleží na datech. Proto je 
dobré dělat specializované shrinky na ob- 
rázky nebo texty (ne, to je blbost, ale k tex- 
tům se ještě dostaneme), obecně to takhle 
moc nejde, ledaže byste měli chytrou ruti- 
nu, která by si data osahala, zjistila, co jsou 
zač, případně by zjistila, jaký značkový bajt 
je nejlépe použít. Takhle to dělá Horatius. 
Ale příklad si z něj neberte. 


E NÍ 


PO U a L E 1D 





Busy při psaní svého komprimujícího ko- 
píráku použil jiný způsob, a protože podob- 
ný používá i moudrý Zilog a je zabudován 
i do PK Lite a Turbo imploderu, samozřejmě 
s drobnými odlišnostmi, zase neuškodí, 
když ho trochu víc rozvedu. Ale v podstatě 
není ani co rozvádět. Značkový bajt jako ta- 


kový není žádný bajt, ale 1+7 bitů, celkem 
osm. První (většinou sedmý) udává, zda ná- 
sledují data pakovaná nebo „blbá“, nepako- 
vatelná. To je tedy značkový bit. Zbylých 7 
udává kvantitativní množství, tedy až 128. 
A pak následuje buď určený počet blbců, 
jak je trefně terminuje Zilog, nebo jeden 
bajt udávající, co se má opakovat, ten se 
pak jmenuje „proudová data“. 

Absolutně nepakovatelný blok se vám 
pak vlastně prodlouží o 1 bajt na každých 
128 bajtů, tedy blok ze samých neopakují- 
cích se blbců se vám na kilo prodlouží o 8 
bajtů. A bajty pakované jsou smrsknuty do 
pouhých bajtů dvou, tedy lépe, než u znač- 
kového bajtu. Jestli jste si všimli, tady je 
značkový bit ten, co ukazuje, zda jde o blb- 
ce, nebo packdata. No a pro pochopení 
ukázka: [blbci,4] blb blb blb blb [pack,4x] 4 
[blbci,2] blb blb. 

Pro úplnost, PK LITE a Turbo imploder 
používají značkový bit stejně jako Zilog. 
Turbo Imploder má ale rutinu o 14 bajtů 
kratší než PK LITE (neplatí pro další meto- 
dy, tam je to naopak). U MrPacka je to 
s RLE těžší. Starší PackMaker používá rov- 
něž značkový bit, ale ne sedmý, nýbrž nultý 
me, proč). RLE nebo shrink s značkovým 
bitem se nemusí používat jen na celé baj- 
ty, původní RLE bylo na opakující se bity, 
ale je s tím pomalá a piplavá práce, rutiny 
jsou pak složité a stejně, podle odborné li- 
teratury pak takové spakované bity seže- 
rou celý jeden bajt, v případě pakování 
RGB pouhé 4 bity, ale ten efekt asi nebude 
moc good. V celobajtové podobě, jak jsem 
ho popsal, se dá použít i na screeny, a to 
nejen v pakování po zpřeházených mikro- 
řádcích, jak to známe z loadování screenu, 
ale i po řádcích, sloupcích, ba i cikcak 
nebo po dlaždicích. Koneckonců slavný 
Pressor VI používá 4 metody shrinku pro 
pixely a další 4 pro atributy... Když jsem 
mluvil o různě velkých paketech, jistou mo- 
difikaci používá, narozdíl od staršího Pack- 
Makeru, MrPack. Vyzkouší normální shrink 
bajtový (stejný jako u MRPACKUu, jen rutina 
je o 6 bajtů delší, snad kvůli BASICMOVE) 
a pak se snaží pakovat dvojbajty (16 bitů, 
tzv. word), použije ten, který dopadne lépe, 
což je pokaždé nějaký jiný. Takže až bude- 
te porovnávat účinnost packerů, zjistěte si, 
kterou shrinkovací metodu MrPack použil. 
Shrink se v opravdových velkých pakáto- 
rech používá pro alokaci volného místa pro 
rozsáhlá data jiných metod, například pro 
Huffmannův strom, CCITT slovník, nebo 
druhý screen při pakování MrPackem. Co 
nesmím zapomenout zmínit je to, že použi- 
jete-li tuto metodu jako první a značkový 
bit u blbců vám blok při pakování prodlou- 
ží, ten vám přeteče přes pakovaná data 
a jste v hajzlu. Zilog to řeší tak, že nechává 
blok přetéct dolů, pakujete-li tedy blok od 
23296 do konce paměti, stoprocentně 
vám přeteče do atributů, pokud pakujete 
od 26000 výš, musíte počítat s tím, že na- 
rozdíl od ostatních se projde i po prostotu 
pod 26000, pozor tedy na CLEAR 25999! 
PK LITE, CHAR, Turbo imploder a další se 


při přetečení jednoduše složí, znáte to - 
PACK ERROR, DATA LOST, a to i tehdy, kdy 
by data šla dále spakovat (škoda jich). 


CCITT aneb co z PeCe 
nevleze do SPECCe 


CCITT je řada algoritmů Consultative 
Commitee for International Telegraphy and 
Telephony, spousta lidí si je plete s Huff- 
mannem. Jedna z jejích verzí sice Huff- 
mannův strom používá, ale jinak je to něco 
jiného. Jsou to metody symetrické a kupo- 
divu rychlé. Tím, že jsou symetrické, se liší 
od implodu a LemplZiva, případně Lempel- 
ZivWelche. Princip je asi ten, že se vyhle- 
dají časté motivy, určuje se četnost a dél- 
ka. Čím delší je motiv a větší jeho frekven- 
ce výskytu, tím kratším kódem je nahra- 
zen. To by bylo hezké, ale, jak jsem zjistil, 
tabulky četnosti motivů byly jednou pro- 
vždy spočítány a zveřejněny, metoda tedy 
není adaptivní a vyžaduje při práci slovník 
motivů. Výsledný kód bývá až 16krát krat- 
ŠÍ, než zdroj, nevýhodná data se ale mů- 
žou 5bkrát prodloužit. Na PeCi se takhle 
kóduje TIFF, CGM a telefonní aplikace, tře- 
ba faxy, a to zejména díky vysoké rychlosti 
a symetrii komprese. Jak jsem ale kdesi 
slyšel, do spakovaných paketů se přidávají 
redundantní, tedy zbytečná data, která 
slouží pro vzpamatování se z poruch při 
přenose, například každý bajt se vysílá 
dvakrát po sobě a podobně, takže PCčkáři 
si komprese stejně moc neužijou, když ji 
pak zas nafukujou... a to by k CCITT bylo 
vše, na Spectru jsem na ni doufám ještě 
nenarazil... 


Lempel Ziv Welch 
(a IMPLOD!) 


Zilogova geniální úprava tohoto algoryt- 
mu z roku 1977 od pánů Lempela a Ziva, 
zvané LZ77, roku 1984 vylepšené Welchem 
pro použití v diskových řadičích, se nazývá 
LemplZiv. A je skutečně geniální a od toho, 
co tito pánové zplodili původně, se i dost 
liší. Tak začnu obecně tím, co to imploze je. 
Je to metoda neztrátová. Světe, div se... 

a totálně asymetrická. Pack není z nejrych- 
lejších, ale aspoň nemusíte pak při depac- 
ku čekat. Pro LemplZiv to platí jen částeč- 
ně, vypadá to, že ďábelskej Zilog spáchal 
dost ďábelský program, takže i pack je na 
implozi dost ďábelsky rychlý. Spočívá ve vy- 
hledávání stejných motivů, které se odkazu- 
jí buď samy na sebe, do okna nebo do slov- 
níku, a to i rekurzivně (i když nevím, kdo tu 
rekurzi používá), ovšem s tím, že slovník je 
plně dynamický, některé varianty metody 
dokonce mohou poznat pokles efektivity 

a příslušným způsobem samomodifikovat 
už existující slovník! Nezlobte se, když budu 
používat dost slaboduché ukázky, ale sám 
jsem ducha mdlého, tak abych tento článek 
vůbec pochopil... VODOVOD VODOPŘEVODY 
PŘEVODY jsou nespakovaná data. [1]o[1] 
[1]o[2] [2] jsou data spakovaná. Slovník je 


pak takovýto: 1: VOD 2:PŘE[ZJY No a teď 
jsem vám doufám vysvětlil smysl rekurze, 
ještě jednou si prohlédněte slovník a zkuste 
si „rozpakovat“ spakovaná data. A jak vidí- 
te, pro texty je to metoda vhodnější než RLE 
(nepočítáme-li pohádky pana Wericha 

pack textu v Desktopu sice opravdu zkracu- 
je (je to specializovaná RLE, jakýsi hybrid), 
ale ani ne moc ten text, jako spíš nadbyteč- 
né mezery, podtržítka a podobně. 

Odkazování do slovníku jste snad pocho- 
pili taky, prostě máme extra text a extra 
slovník, dá se to použít na textové pressory, 
které čtou text zahuštěný, pro inspiraci ote- 
vřte knihu ASM a ZXS 4. díl nebo se podí- 
vejte na Caesara. 

Odkaz samo na sebe nebo do okna vy- 
padá přibližně následovně: V závorce je [od 
kolikáté pozice, kolik znaků], při počítání 
uvažuji v závorce dva znaky: VODO[1,3] 
[1,3]lopře[1,3]y [11,5]. Pozice se ukazuje 
adresou buď absolutní, tedy skutečnou, 
nebo relativní, kdy se počítá od začátku 
bloku. Protože adresa spotřebuje moc bitů, 
vlastně dva bajty, trochu se to omezuje. Na- 
víc nějaké chytré hlavy stejně zjistily, že op- 
timum je asi čtyřkilové „okno“, je dost 
malé, aby nezdržovalo a dost velké, aby 
komprese moc neutrpěla (není to sice na 
první pohled tak účinné, ale zas se ušetří 
adresací). Zilog používá okno 4kilové, PK 
LITE, CHAR a Turbo Imploder mají okno jen 
dvoukilové a odkazují se ne od začátku 
okna, ale zpátky, od pakovacího kurzoru. 

A pro zajímavost - Caesar okno nemá vů- 
bec, tedy lépeřečeno ho má nekonečně vel- 
ké. Abyste to pochopili, ukážu vám takové 
desetiznakové okno: VODOVOD VODblagwo- 
ertyu VODOVOD jsou nespakovaná data. 
vodo[-4,3] [-7,3]blagwoertyu vodo[-4,3] jsou 
data spakovaná. Jak vidíte, druhému vodo- 
vodu už první vodovod vytekl z okna a už se 
na něj nemohl odkazovat, vypadá to, že úpl- 
ná adresace by to ještě o znak zkrátila, ale 
protože adresace do okna je kratší než ad- 
resová a my tu máme adresace tři, tedy trojí 
zkrácení na jedno prodloužení, je výsledek 
vlastně supr. V praxi to tak dopadnout ne- 
musí, ale podle hlav matematiků to za opti- 
málních podmínek dopadne takhle. Pokud 
na optimální podmínky nevěříte, při psaní 
svého packeru vyzkoušejte obě možnosti, 

s oknem i s celkovou adresací. 

Jak teď rozeznat pack? Nabízí se znač- 
kový bajt a skutečně to páni Lempel, Ziv 
a Welch dělali přes něj. Ne tak náš hodný 
a geniální Zilog, ten si zavedl značkový bit. 
Jeho metoda pak pakuje takto: Jeden bajt: 
7. bit značka pro blbce, zbytek délka (až 
128 blbců). Následuje patřičný počet ne- 
spakovatelných dat. Jeden bajt: 7. bit znač- 
ka packu další tři bity je délka motivu 
zmenšená o 3 další čtyři+další bajt (12 
bajtů) pozice ve 4kilovém okně (všimněte 
si, že 12ti bity naadresujete právě 4 kila). 
Sbalená data se nám pak vejdou do dvou 
bajtů. Když tak sbalíme trojbajtový motiv, 

o bajt se zkrátí. Balit kratší nemá cenu, še- 
tříme tedy bity a těmi třemi v osmi kombi- 
nacích můžeme označit motiv dlouhý až 


11 bajtů. Musím říct, že tohle se mi cel- 
kem líbí. PK LITE, Turbo Imploder a Char 
používají, zdá se, značkový bajt, pokud je 
to blbec, následuje za ním nula (tím se 
pack zbytečně prodlouží, bohužel), další 
dva bajty pak určují adresu a délku moti- 
vu, vyberte si sami, která metoda je lepší, 
značkový bit obecně má tu nevýhodu, že 
prodlužuje nespakovatelná data, ale má 
kratší data spackovaná, značkový bajt, po- 
kud je to bajt, který se v bloku nevyskytuje 
(což za obecných podmínek zaručit nelze 
a je to nepravděpodobné), k prodlužování 
příliš nepřispívá (za obecných podmínek 
přispívá, viz prodlužování u shrinku), hlav- 
ně mu ale nevadí libovolný počet blbců. 

U LempliZiva od Ziloga se prodlužují jen 
blbci (8 bajtů na kilo), sbalená data jsou 

o bajt na každé sbalení kratší. Jde jen o to, 
čeho je víc. Blbců nebo sbalených dat. 
Abyste měli jasno, sdělím vám tajemství. 
Zilog data stejně skoro vždycky spakuje líp 
než nějaký Turbo Imploder... IMPLOD v PK 
LITE a CHARu je jedno a to samé, progra- 
mátoři moc fantazie neukázali. Totéž platí 
pro Turbo Imploder, který má ale rutinu 

o jeden bajt delší... Další zajímavostí 

u těchto pakátorů je fakt, že někdy můžete 
implozi pustit až třikrát přes sebe, výsle- 
dek bývá ohromující, většinou ale při tře- 
tím, někdy až čtvrtém průchodu, zahlásí 
přetečení. Nepříjemná skutečnost, že pro- 
gramátoři opisovali jeden od druhého sta- 
ré, byť osvědčené, rutiny, je příčina toho, 
proč máme na Spectru sice dost pakátorů, 
ale málo metod, mezi kterými bychom si 
mohli vybírat. 





Huffmanne, Huffman- 
ne, Huffmanne, vždycky 
na tě dojde 


Už jsem snad říkal, že nemám rád bito- 
vé komprese a držím se pevné půdy celých 
bajtů. Chcete-li se stát milovníky Huffman- 
nova kódování, což bych vám ještě nedáv- 
no nedoporučoval, musíte celé bajty opus- 
tit ať chcete nebo ne. Princip jsem nastínil 
už u CCITT, u Huffmanna je to v podstatě 
děláno tak, že si spočítáte výskyty jednotli- 
vých bajtů (možná by šly i dvojbajty, ale 
zkuste si pořizovat asi tak 65535 kódů), 
ten nejčastější nahradíte nejkratším bito- 
vým kódem a ten nejčastější nejdelším. 
Pokud jsou všechny v datech obsažené 
bajty přibližně stejně četné, Huffmann 
zklame. Ty kódy ale musejí nějak vypadat 
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a my musíme poznat, který je který a jak je 
dlouhý. Ideální se jeví ukončovací sekven- 
ce (ovšem jenom jeví, už dávno se nepou- 
žívá, tedy od té doby, co vznikl Huffman- 
nův strom). Vybrali-li byste si jako konec ře- 
tězce bitů dvě jedničky, tedy 11, nemůžete 
je použít nikde uvnitř řetězce, musíte se 
pak spoléhat na sérii 10101, občas prolo- 
ženou nulou. Délka řetězců tak brzy naros- 
te. Pokud použijete jako ukončovadlo jed- 
ničky tři, jsou kódy zpočátku trochu delší, 
ale neprodlužují se s časem tak rapidně. 
Bohužel k vyrovnání dojde až při délkách 
kódu větších než 1 bajt. No prosím. To zna- 
mená, že u prvního způsobu se nám zkrátí 
výskyty dvaceti bajtů, u druhého pouhých 
patnácti, úspora je bohužel vidět až u má- 
lo četných výskytů, ale tam jsou už kódy 
dlouhé hodně přes bajt. Tady vidíte, že až 
zas tak moc supr geniální metoda to není. 
Vždyť jsem to říkal. Ukončovací sekvence 
se nepoužívají, protože máme dávno něco 
lepšího. Huffmann se jmenuje Huffmann 
podle Huffmanna, který si lámal svou ma- 
tematickou hlavu tak dlouho, až vymyslel 
strom. Princip je asi tento: Jednička nebo 
nula znamená větvení doleva nebo dopra- 
va (obrazně řečeno). No a nějakou mate- 
matickou metodou se dá odvodit, jestli se 
ta větev na kterou se takhle dostanu, větví 
dál, nebo je slepá. Pokud je slepá, tak od- 
povídá nějakému znaku (tedy bajtu), které- 
mu, to se přiděluje podle četnosti jeho vý- 
skytu v surových datech a délky kódu vět- 
ve. Protože je Huffmannova metoda pří- 
buzná s CCITT, vyžaduje slovník kódů, kte- 
rý umisťuje buď do místa vyšetřeného 
předchozími metodami (MrPack), nevejde- 
li se, tak do obrazovky (MrPack), u TREE 
PRESSu a PK HUFFu si adresu volíte sami, 
v podstatě si ale vybíráte z výše uvede- 
ných možností. Protože slovník musí být 
součástí rutiny a není zrovna nejkratší, má 
rutina MrPacka a PackMakera skoro dvě 
kila. PK Huff a Tree Press sice taky na 
slovník spotřebují 1024 bajtů plus asi 100 
bajtů pro rutinu, součástí rutiny je ale krát- 
ký podprogram, který strom kódů sám vy- 
generuje, proto se blok skládá jen z dat 

a stobajtové rutiny. Zilog to dělá podobně, 
generuje strom, původně asi čtyřicetipatro- 
vý, ale při optimalizacích ho stále zmenšo- 
val, zdá se, že v hotovém packeru to bude 
jen něco kolem 30ti, tím se značně strom 
zkrátí a nebude žrát tolik paměti. Ještě 
jednu výhodu Zilogova rutina má. Je drsně 
rychlá. Pomalu ani nevěříte, že je to Huff- 
mann. Nevěříte-li, nahrajte si jako ukázku 
MGSUxx, upozorňuji ale, Že tady je depako- 
vání zpomaleno, aby se dalo lépe sledovat, 
co to vlastně dělá. Nepletu-li se, Matsoft 
sliboval, že má krásný popis nějakého kon- 
krétního Huffmanna, modlete se, aby ho 
do ZX Magazínu dal, možná z toho pak bu- 
dete moudřejší. Tree Press a PK Huff jsou 
úplně jedno a to samé, liší se jen trošku 
vzhledem, třeba Tree Press nemá ukazatel 
úspěšnosti, ale program je vlastně tentýž. 
Jsou plně interaptovatelné, jako imploze, 
což se ale nedá říct o MrvPacku. PK Huff 
A Tree Press mají jednu velkou nectnost. 
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Strašně rády hlásí PACK ERROR, DATA 
LOST. Výkonem je sice huffmann z Pack- 
makera předběhne, ale ten nejde použít 
samostatně bez shrinku. Jak se liší Mr- 
Pack a Packmaker? MrPack má rutiny o 6 
bajtů delší než Packmaker, použitelné 

z něj je ale Basicmove, to jiné packery 
nemají, a pokud chcete použít loader vy- 
tvořený Pressorem VI, musíte použít i SAVE 
z MrPacku (nemusíte v něm pakovat, stačí 
skutečně jen SAVE), které přidá do hlavičky 
souboru data pro loader. Co je na packe- 
rech od Mixoftu zajímavé, jsou strašně 
prasecké rutiny (i když je v nich pár zajíma- 
vých nápadů), které se nesnášejí s prog- 
rámky pod přerušením. Rutina se ukládá 
defaultně na zásobník, prostě počítá s tím, 
že je tam pro ni místa dost). Nejzajímavější 
ale je, že pack netrvá až tak dlouho (mlu- 
vím o PackMakerovi), zato depack (a teď 
mluvím o Huffmannovi z PackMakeru) 
dlouho trvá. Ona holt práce s bity a ne- 
ustálé rotace zdržují a je to pomalé. 

K chvále Ziloga musím podotknout, že on 
to takhle pomalé nemá. Poslední poznám- 
ka k Huffmannu, a mám tím na mysli Mr- 
Pack a PackMaker. Jsou sice účinnější než 
jiné Huffmanny (mysli Tree Press a PK 
HUFF, ne Zilogův packer), ale na implozi 
prostě nemají ani co do výkonu, ani co do 
rychlosti depacku. Takže imploze Huff- 
mann 1:0. Připsal bych ještě něco o frak- 
tální kompresi, která je žhavou novinkou 
ve světě PeCÍ, ale je ztrátová, tak se jí my 
zabývat nebudem... 


Strašidelná otázka 


Říkal jsem, že mne k zájmu o packery 
hnala otázka, který používat. Abyste ne- 
museli hledat sami, dám vám odpověď. 
Píšete demo, data se vám do paměti na- 
ráz nevejdou, potřebujete pakovat, ale ne- 
chcete vypínat IM 2 a nějaké ty efekty. 
Přitom chcete, aby depack nebyl bleskový, 
abyste během depakování mohli nechat 
běžet nějaký efekt (viz Dies Irae, napří- 
klad). Tady se dá použít PK HUFF. Ve 
všech ostatních případech použijte PK 
LITE. Imploze je rychlá a rovněž plně inte- 
raptovatelná. Tady máte dvě možnosti: 
nechat proběhnout shrink a pak až do 
omrzení prohánět blok implozí, nebo se 
na shrink vykašlat a prohnat blok více im- 
plozemi. Doporučuji pouštět imploze po 
jedné a blok sejvovat (co kdyby se vám 
packer při příští implozi sesypal), při dal- 
ším průchodu nezapomeňte, že blok se 
zkrátil (v odpovědi na dotaz Lenght). Ne- 
bojte se, že je to nevýhodné, kdybyste dali 
více průchodů automaticky, byl by výsle- 
dek stejný, navíc Turbo Imploder víc prů- 
chodů neumí a musíte je datlovat ručně. 
Pozor na shrink z Turbo Imploderu, občas 
špatně depakuje, asi díky o 14 bajtů zkrá- 
cené rutině. Vyvarujte se tedy samotného 
shrinku. U PK LITE to neplatí, tam je 
shrink naprosto bezpečný (málokdy ale 
potřebujete samotný shrink). Potřebujete- 
li blokem nějak hýbat, použijte CHAR- 
press a volbu Modify depacker. CHAR- 


press umí nahrávat soubory, hodí se tedy 
pro pakování her, které jsou rozprostřeny 
od 23296, defaultní umístění depakovací 
rutiny pak musíte přesměrovat buď do 
volného místa (vždycky nějaké je, v pamě- 
ti přece bývají loadery, zbytky basicu 

a tak), do obrazovky jen v nouzi (umisťo- 
vat do VRAM jakékoliv depakovací nebo 
LDIRovací rutiny je prasárna). Potřebujete 
zobrazit panel (druhá obrazovka MrPacka 
a PackMakeru). Pressor VI a Packmaker 
s volbou 2" screen je jen pro mentáčky. 
Šikovnější zapakuje obrázek CHARem 
(depack je pak rychlejší než z PRESSORu 
a i výsledný blok je kratší, jen pozor na 
ztracenou relokovatelnost) a přilepí ho 
do místa uvolněného prvním průchodem 
packu hlavního bloku (autostart je dobré 
nastavit na depack hlavního bloku). Výsle- 
dek se většinou dá ještě zdrcnout implo- 
zemi (autostart na depak obrázku). 

Potřebujete balit textovku nebo pro- 
gram, který obsahuje basic. Nelze-li kompi- 
lovat (Softek FP umí kompilovat i kazetoý 
LOAD a SAVE), použijte Basicmove 
v MrPacku, ale nepakujte. Blok pak nějak 
dostaňte do PK LITE (většinou ho nemusí- 
te ani sejvovat, stačí nahrát PK LITE 
a nadatlovat správná data). 

Na normální obrázky používejte radši 
PRESSOR kvůli relokovatelnosti (úvodní ob- 
rázky ale stejně umisťujte na 4E4). 

Chcete něco zapakovat velmi rychle, ale 
chcete, aby se uživatelé zbláznili při čekání 
na depack. Pak použijte PackMaker... 
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Pozor ale! Tohle bude platit jen do té 
doby, než Zilog dokončí svou KomprimAci! 
Vzhledem k tomu, že má mít zabudovánu 
i speciální podporu packu obrázků, je mož- 
né, že většinu starších packerů budete 
moct zahodit daleko, předaleko... Před čím 
vás tedy budu varovat? Já to sem už na- 
psal, ale stejně to zopakuji. Vsssžžžž! Sly- 
ším MrvPacka, vidím MrvPacka! Tady se 
podepsal zas někdo neinteligentní. Říkám, 
imploze je lepší jak časově, tak výkonově... 
Na obrazovce problikl úvodní obrázek, teď 
už je vidět jen tma a v dálce je tušit de- 
pack. Pokud si VRAMku dobře prohlédnete, 
najdete tam depakovací a LDIRovací rutiny. 
Nechci nikoho pomlouvat, ale je to častá vi- 
zitka JSH. Klackson Hollis se už asi nepo- 
lepší, ale vy ho v tomhle radši nenásledujte. 


Zpackaný text 


Ano! Spáchali jste text a chcete ho za- 
balit. RLE na pakování textů není vhodná, 


to už víme. Huffmann se nehodí. CCITT by 
bylo na místě, ale pokud vím, Spectristé 
ho neprovozují (škoda). Tolkien je speciali- 
zovaný implod. Tak a teď víte skoro vše. 
V textech se především nevyskytují, jako 
v obecných blocích, všechny znaky. 
| s češtinou je písmenek méně než 128. 
Budete-li se snažit narvat text do 7mi bitů, 
ušetříte na 8mi bajtech jeden bajt, na kile 
pak 128 bajtů (87,5%). Není to špatné, ale 
není to zas tak výkonné. Dal by se použít 
značkový sedmibit, ale dělejte se s implo- 
dem v neustálých rotacích... Vraťme se 
radši k celým bajtům. Když jsem páchal 
Caesara, srazil jsem češtinu (desktopác- 
kou, jak jinak) do kódů 1 až 16, ENTER 
skonvertoval na 31 (mám aspoň ten do- 
jem) a krom několika nevyužitých bajtů 
(škoda jich, ale to jsem zjistil až dodateč- 
ně) se mi vše vešlo od 1 do 127. Nula zna- 
menala oddělovník v tabulce slovníku. 
Kódy 128-255 nesly (krom značkového 
bitu) i číslo, které znamenalo pořadí slova 
ve slovníku. Vlastní pack pak pracoval asi 
takto: [1]o[1] [1]0[2][2]OvodOpře[1]y0. 
Pokud nevíte, co jsem to pakoval, byl to 
náš cvičný text z kapitoly o implodu. Nejpr- 
ve je vlastní text, pak nula, první slovo 
slovníku, nula, další slovo slovníku, etc. 
V podstatě tedy implod se slovníkem. Jedi- 
ná chyba byla ta, že v zájmu nečitelnosti 
textu jsem pakoval i takové kombinace, 
které se packem nezkrátily, ale tabulku 
okupovaly. Vidíte, že jsem měl místo na 
128 odkazů. Takhle se rychle zaplnily 
a účinek nebyl tak velký, jaký by mohl být. 
George K. to udělal fikaněji. Všechny zna- 
ky si srazil do intervalu O až [počet znaků]. 
Potřeboval sice tabulku navíc, ale nešť. 
Písmena v textu pak nahradil jejich pořa- 
dovým kódem v tabulce a právě tím se stal 
text nečitelný, i kdyby ho nikdo nepakoval. 
Vzhledem k tomu, že málokdy máte v textu 
127 různých písmen, měl víc odkazů na 
slovník než já a tím i lepší kompresní po- 
měr (navíc pakoval skutečně jen to, co text 
zkrátilo, a neplýtval tak zbytečně odkazy). 
Proč se u textů používá slovník a u nor- 
málního implodu ne? LemplZiv (píšu teď 
opět o Zilogově modifikaci) nemá volnou 
paměť, kterou by slovníkem mohl obsadit, 
protože slovník musí být k dispozici až do 
konce depaku. Zato texty zůstávají v pod- 
statě stále zabalené a slovník nikde nepře- 
káží, naopak odkazy samy na sebe (ne-li 
dokonce do okna) narážejí právě na to, že 
se nerozbalují a odkážete-li se na něco, co 
se za chvilku zabalí a už se to nerozbalí, 
dost tvrdě ztroskotáte. Pokud jste četli im- 
plod pozorně, všimli jste si, že se obvykle 
odkazuje do části, která je při depaku už 
depakovaná. 


Crack! 


Crackujete-li pakované hry, máte to 
jednoduché hlavně u MrPacka. Ten se to- 
tiž vždy vrací přes return. Volá-li se pack 
ze strojáku, je to jen obyčejný CALL. Větši- 
nou ale stačí hru po depacku BREAKnout 
a jste uvnitř (skoro, ještě se totiž může 


všelijak LDIRovat...). U PK LITE a odvoze- 
nin bývá nastavený autostart. Pokud ruti- 
na začíná LDIRem, je to implod a vám 
stačí jet po kódu tak dlouho, dokud nena- 
jdete 3x za sebou RRCA. Za chvilku přijde 
jeden JR NZ a hned za ním je příslušný JP, 
který spouští hru nebo další průchod. Za- 
číná-li rutina JUMPem na konec spakova- 
ných dat, je to shrink. Pokud se hned 

v úvodu pushuje hl, bude se pravděpo- 
dobně skákat na adresu v něm uloženou. 
Nepushuje-li se hl, bude se asi za chvilku 
pushovat de a to znamená, že rutina ská- 
če normálně na začátek depakovaného 
bloku. Rutiny si ještě ukážeme. Není nic 
jednoduššího, než Devastací změnit JP 
na RET (201) nebo PUSH na NOP (0). Pak 
nechte proběhnout depack a podívejte 
se, zda se chystá další průchod, nebo zda 
je už hra rozpakována. Hotovo. Jak potom 
cracklou hru packovat, to už snad vysvět- 
lovat nemusím... 


ři L] 
Fi ii Hčrě: 
Fast n 


Jak má depack vypadat 


Mluvil jsem o PUSHích čehosi, na co se 
pak skáče RETem. I MGSuxx začíná instruk- 
cemi LD HL,xxx:PUSH HL:LD HL,yyy:PUSH 
HL:LD HL,zzz:PUSH HL. Tím se nastaví volá- 
ní dalších průběhů a startu programu, pří- 
slušné adresy se ocitnou na zásobníku a ru- 
tině pak stačí mít v sobě už jen RET a o víc 
se nemusí starat. Pokud na závěr nic nepu- 
shneme, program hru nespustí, ale vrátí se. 
Ne vždy je to ale výhodné. Lze to dělat, plní- 
li se nám nějaký registr číslem adresy, na 
kterou si přejeme skákat. Tím ušetříme 1 
bajt. Pokud ale musíme registr plnit uměle, 
prodlužujeme rutinu o 2 bajty (v případě 
MGSuxx, kde jsou volání tři, je rutina proti 
třem JUMPům prodloužena o 6 bajtů). 

LD DE,16384 
LD HL,40000 
LD BC,6912 
LDIR 
JP 16384 
To je asi 13 bajtů. Střední hodnota. 
LD DE,16384 
PUSH DE 
LD HL,40000 
LD BC,6912 
LDIR 
RET 
A tohle je jen 12 bajtů. To 16384 bychom 
do dvojregistru DE cpali tak jako tak. 
LD HL,50000 
PUSH HL 
LD DE,16384 





LD HL,40000 
LD BC,6912 
LDIR 

RET 

A tohle je 15 bajtů. Ne že by na tom zále- 
želo. Je to jen detail, ale tady záleží na kaž- 
dé maličkosti. Chcete, abych vám ukázal, 
jak takovéhle drobnosti úplně znemožňují 
jeden známý packer? Fajn, ještě chvilku vy- 
držte. 

Takhle vypadá imploze z PK LITE nebo 
CHARu: 
START Id hl,RUTINA 
Id de,DEPRES 
jobvykle se rutina přesune na 234800 
nebo 23500, tedy pod systémové proměn- 
né. U Turbo Imploderu umístění rutiny ne- 
můžete ovlivnit, u ostatních ano. 

push de 
sjtady se využije toho, že adresu tak jako tak 
v de máme. 

Id bc,RUTLEN 

Idir 

ret 
„proti tomuto skoku není námitek. 
RUTINA Id de,START 

Id bc,DATALEN 

Idir 
jv hl se ukazovalo na data. 

Id hl,DATAEND 

ex de,hl 
„depakuje se odzadu, v de je teď konec depa- 
kovaného bloku, v hl konec pakovaných dat. 
NEDEP dec hl 

dec de 

Id a,(hl) 

Id (de),a 

sub 137 

jr nzNEDEP 
sta 137 není povinná, je to prostě značkový 
bajt. 

dec hl 

or (hl) 

jr zDEPAK 
„pokud následuje O, nebude se pakovat, 
protože to byla 137ka skutečná. 
Následuje část, kterou ani nebudu popiso- 
vat. Z následujících dvou bajtů se vyfiltruje 
začátek a délka odkazu a Iddrne se. Sou- 
částí této části jsou i ony nápadné tři rrca. 
Okno je na rozdíl od Zilogova LemplZiva 
pouze dvoukilové (adresované 11ti bity). 
Délka odkazu je zmenšena o 3 (je tu proto 
add a,3). Je doufám jasné, že odkazy smě- 
řují do už rozpakované části. O tom, že lepší 
než značkový bajt by byl značkový bit, jsem 
už psal. Trochu nepochopitelné je, že shrink 
z toho samého packeru značkový bit použí- 
vá. Stejně tak je zajímavé, že rutiny shrinku 
a implodu jsou jinak organizovány, ačkoliv 
je snad psal jeden a ten samý autor... 
DEPAK sbc hl,de 

add hl,de 

jr nzNEDEP 

jp START 
„do tohohle jumpu se píše startovací adre- 
sa. V případě, že je stejná jako START, bylo 
by lepší mít za návěštím RUTINA, kde LD 
DE,START máme, PUSH DE a tady RET. 
DATABEG 
„následují pakovaná data. 


Programování 


To nebyla věru špatná rutina. V CHARpressu, 
když si dáte Modify depacker, se vám číslo, 
které dáte jako Unpacked at, uloží za návěští 
RUTINA. Protože se LDIRuje a ne LDDRuje, 
můžou se bloky překrývat, pokud jimi hýbete 
dolů, ale nesmí se překrývat, pokud jimi hý- 
bete nahoru. Nevyplácí se na to zapomínat. 
Asi jsem na to měl upozornit už dříve. 
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Jak nemá vypadat depack 


Slíbil jsem znemožnit jeden packer. Podívej- 
te se nejdřív, jak deshrinkuje PKLITE. 
START jp RUTINA 
„zbytečné tři bajty navíc. Lepší by bylo umís- 
tit na začátek rutinu rovnou a až pak data 
DATA | defbO 

defb 228 
sblok se skládá ze sta nul (228-128 je 100), 
data jsou ukládána odzadu. 
RUTINA Id hl,RUTIN2 

Id de,DEPRES 

Id bc,RUTLEN 

push de 
steď už víte proč... 

Idir 

Id hl,DATA 

Id de,START 

Id bc,DATALEN 
„zbytečné plýtvání místem, všimněte si, že na- 
rozdíl od implodu tu rutina nemůže použit sta- 
rý obsah registrů. Evidentně je tedy výhodněj- 
ší umístit nejprve rutinu a až pak data. 

Idir 

Id hl,PCKEND 

Id de,DPCKEND 

Id bc,DPCKLEN 
„depakuje se odzadu, ale to už jsem už jed- 
nou nastínil. 

ret 
RUTIN2 Id a,(hl) 

rlca 

srla 
stímhle se do CARRY hodí značkový bit (kdy- 
by byla data „předrotovaná“ RLCAčkem, sta- 
čilo by SRL, zas by se bajt ušetřil). 

dec hl 
NEDEP Idd 

ret po 
„v tomto případě se rutina normálně vrací 
a nic se nevolá. 

dec a 

res 7,a 

jr z,RUTIN2 
;po rozbalení určitého počtu proudových 
dat nebo určitého počtu blbců se zas skáče 
na čtení značkového bitu. 

jr ne,NEDEP 
„blbci mají značkový bit O. Pokud se depa- 
kuje, platí c. 

inc hl 

jr NEDEP 

A to je všechno. Sama rutina je celkem 
krátká. Dala by se ještě vylepšit, to ano, ale 
asi by to musel dělat šikovně chytrý pro- 
gram, který by ji modifikoval tak, aby byla 
pokud možno co nejkratší. 

A teď tu trapnost. Porovnejte prosím se 
shrinkem PackMakeru, metoda je sice 
prakticky stejná, ale metody hrůzně různé. 
START jp RUTINA 


K 


ZX Magazín 2/99 





12 


Programování 


Jjako předtím, veskrze zbytečné 3 bajty. 
DATA  defb O 

defb 201 
„zkuste si to zrotovat doprava, vyjde vám 
228 jako u PK LITE. Je hezké, že má Pack- 
Maker značkový bit předrotován, ušetří tak 
jednu instrukci. Bohužel tento náskok ztratí 
na jiných, odporných a zbytečných kravi- 
nách. 
RUTINA call 82 
„ne, rutina není relokovatelná. Já si myslím, že 
se sem občas poukuje zavolání depacku dru- 
hého screenu. Protože se ale panel využívá 
jen výjimečně, jsou to další zbytečné tři bajty. 

Id hl,81 

push hl 

Id a,i 

jp pe,RUTIN2 

Id a,i 

jp pe,RUTIN2 

pop hl 
„pokud platí PE, zůstane nám na zásobníku 
hnusné číslo, ukazující do ROMky na in- 
strukci El (kterou následuje RET). Tahle 
snůška instrukcí testuje stav přerušení 
(IFF2). Já ale nepředpokládám, že bych byl 
uvnitř NMI rutiny (vy snad ano?), podívejte 
se, co ten vůl vyplácal prostoru. Necpat nic 
na zásobník, odpadlo by mu celé složité tes- 
tování DI a El. Proč se čte stav přerušení 
dvakrát, taky nevím, asi to není moc spoleh- 
livý způsob a tak to radši zkouší dvakrát, 
ale podle toho, co o tom vím, by jednou sta- 


čilo, ušetřily by se asi čtyři bajtíky. Při povo- 
leném přerušení je ho třeba obnovit, při za- 
kázaném se neobnovuje nic, PackMaker se 
totiž o zakázání postará sám. 
RUTIN2 di 
„normálně by to nebylo třeba, ale tady je to 
venkoncem nutné. Proč? Protože zásobník. 

Id de,START 

Id hl,DATA 

Id bc,DATALEN 

Idir 

dec de 
stohle známe. V de teď máme ukazatel na 
konec spakovaných dat (a zas depakujem 
od konce). 

push de 

scf 

sbc hl,hl 

add hl,sp 

ex de,hl 

Id hl,RUTEND 

Id bc,RUTLEN 

Iddr 

ex de,hl 

inc hl 

Id de,DPCKEND 

Id bc,DPCKLEN 

jp (hl) 
„hrůza všech hrůz, odsune rutinu na zásob- 
ník. Ta má sice 16 bajtů, ale nezdá se mi to 
být moc geniální. Vidíte, kolik to jenom té 
nebohé paměti užírá? Proto je PackMaker a 
MrPack naprosto neinteraptovatelný. Pře- 


psala by se mu depakovací rutina. 

pop hl 
„tady se obnoví to odložené de. V podstatě 
od toho dec de až sem to je snůška kravin. 
Stačilo pár instrukcí a nemuseli jsme se in- 
teraptu bát. 
NEDEP Id a,(hl) 

dec hl 

srla 
„tady jsme oproti PK LITE jednu instrukci 
ušetřili (rlca nám udělal už packer). 
DEPAK Idd 

ret po 
stady se buď program vrátí, nebo skočí na 
El a pak teprve se vrátí. Skákat nikam neu- 
mí. Kdybyste ale přepoukovali tu 81, skákal 
by podle toho, co byste mu tam napískali. 

dec a 

jr zNEDEP 

jr ne,DEPAK 
blbci mají značkový bit O, jako u PK LITu. A 
proč ne, když je to vlastně rutina z PK LITE 
upravená nějakým amatérem. 

inc hl 

jr DEPAK 

V podstatě se dá říct, že autor zase tradi- 
ci nezklamal a obšlehl, co se dalo. Metoda 
je ta samá, vlastní depakovací rutina až na 
dvě instrukce (RLCA a RES 7,A) jakbysmet, 
navíc je tam akorát ta hrůza se zásobníkem 
a hrátky s přerušením. 
Zdravím vás a doufám, že se příště bu- 

deme otravovat zase s něčím jiným. u 





Loader s počítadlem 


+GAMA 


Tak co, uživatelé D40, pamatujete se 
ještě na ty překrásné kazetové loadery 
s počítadly??? Pokud jste si hned po této 
první větě řekli, že něco takového musíte 
okamžitě spáchat, vězte, že něco už jsme 
udělali za vás. Před vámi se placatí hrůzo- 
vina nejzacyklenější, mající za účel natáh- 
nout z disku do paměti blok bytes, např. 
hlavní část pakované hry. Od LOADu 
z ROM D40 se liší tím, že se snaží během 
práce zobrazovat vpravdě křovácké počí- 
tadélko. Výpis by měl být komentovaný, 
uvedu tedy to, co se tam už nevešlo. 
Vlastní loader by měl být umístěn tam, 
kde ho nic nepřehraje, podle mého v nej- 
vyšší části paměti. Pakovaná hra by ho 
tam během nahrávání neměla přepsat 
a když už loader nebude potřeba, vaše 
oblíbená pařba se přes něj jednoduše 
rozpakne. Další místo je třeba na FATku, 
která se do paměti nahraje dříve než 
blok. Tu však můžeme blokem přepsat, 
a to také doporučuji. Umístěte ji někam, 
kde se později bude blok vyskytovat, a je 


po problémech. Nejhorší je to asi s 200 
bajty mapy souboru, která se normálně 
ukládá do DRAM, ale myslím si, že polo- 
hou a velikostí nám skvěle poslouží print- 
bafr. Hlavně si hlídejte, aby byla v paměti 
přítomna během nahrávání (bez ní to pro- 
stě nemůže fungovat...). Tyto tři smrtelně 
důležité hodnoty se definují za příkazem 
ORG a u návěští FATKA a ZASOBA. U ná- 
věští JMENO je jméno nahrávaného sou- 
boru, ZACATEK je adresa, kam se soubor 
bude nahrávat. Nejdůležitější je samotný 
tisk počítadla za návěštím PRD, s tím si 
hrajte - svěřuji ho vaší programátorské 
intuici, snad vám vznikne něco hezkého, 
jako obzvlášť dobrý nápad doporučuji ru- 
čičkové (analogové) hodiny... Poslední po- 
známka - volané strojové rutiny fungují 

i při použití MDOSu 2.0 (tj. už i na Kom- 
paktech to musí fungovat). 


org 65000 „Tady to začíná. 

YEDEME Ida,2 ;Otevřít kanál pro tisk 
call +1601 ;počítadla do obrazovky 
Id hl,ZACATEK sa začátek souboru uložit 
Id (LDADR+1),hl ;do hloubi programu. 


pro VIDOS 


PAGE Id a,4t4F „Přestránkujeme na 
Id de,TAB-26; „DROM. 
call 4£25AB 
Id hl,0 
Id (TAB),hl 
Id hl,43EF7 
Id (TAB+2),hl 
rst 0 

CMUCHEJ call 7311 „Atakujeme disketu. 
Id hl,FATKA „Na známou adresu si 
Id de,5*256+1 „uložíme FATku. 
Id bc,1 
call 8866 

FINDFILE Id hl, JMENO „Fajl s tímto jménem... 
Id de,16010 
Id bc,11 
Idir 
call 8491 ;..„zkusíme najít. 
jp nz, NENITU „Odskok, není-li tady. 
Id (15986),hl; „Délku souboru... 
push hl 
pop iX 
Id d,(ix+12) /... kterou sebereme 
Id l,(ix+17) stuhle, s prvním sekto- 
Id h,(ix+18) „rem souboru... 
Id ix ZACATEK 
srld ;..„vydělíme 512... 


inc d 

da,d 

d (POCIT+1),a 
call PRD 

d bc,ZASOBA 
push hl 

call FDBLOCK 
d hl,3072 
sbc hl,de 

ret z 

da,d 

cp 14 

jr ne,POSLEDNÍ 
pop hl 

d (ULOZ+1),bc 
d (0),hl 

inc c 

inc c 

call FDBLOCK 
ex de,hl 

jr DF1 


DF1 


ULOZ 


POSLEDNÍ xor a 

d (bc),a 

inc c 

d (bc),a 

inc c 

pop hl 

d (ULOZ1+1),bc 
d (0),hl 

dh,b 

dl, 

incl 

inc | 

d (hl),e 

inc | 

d (hl),d 

d bc,ZASOBA 
Id a,(bc) 

dla 

inc c 

da,(bc) 

dh,a 

inc c 

orl 

jp z,POSLEDNÍ 
push bc 

push hl 
da,(POCIT+1) 
deca 

d (POCIT+1),a 
call PRD 

call DIVIDE 

Id hl,0 

d de,257 

call 8866 

d hl,(LDADR+1) 
inch 

inch 

d (LDADR+1),hl 
pop hl 

pop bc 

jp LOAD 


ULOZ1 


LOAD 





LDADR 


POSLEDNÍ Id h,b 
dl, 
dc,(hl) 
inc | 
db,(hl) 
inc | 
de,(hl) 





+To je počet sektorů, 
„který by bylo hezké si 
„uložit... 

„...a vytisknout. 


„Hledáme další sektor. 
„Test na prázdný soubor. 


„Soubor má délku 0, návrat 
„Test na poslední sektor 
souboru. 
CHYC 
+Číslo sektoru si uložíme. 


„Hledáme další sektor 
souboru, 


„uděláme si koncovou 
„značku (dvoubajt 00) 


DIVIDE 


sa za ni uložíme číslo 
„posl. sektoru v souboru. 


DVO 


rČíslo sektoru, který 
„se teď bude ládovat 
sz disku, 
„vyzvedneme z mapky. 
FDBLOCK 


„Je-li to dvounula, násle- 
„duje už jen posl. sektor. 
„Zbavíme se ukazovátka 
sa čísla sektoru, 
„číselník snížíme 

;o jedničku 


MORE 


sa zobrazíme si ho. 
+Číslo logického sektoru 
„se přepočte na stopy 
ja fyzické sektory, 

„aby se mohl načíst. 


„Zvětšíme si adresu o 512 


a napoukujeme! 
„Obnovíme 

„ukazovátko 

;a jdeme na další sektor. 


ODD 


NODD 
„Po koncové značce si 
„načteme číslo posled- 
„ního sektoru. 


BOTH 


inc | 

Id d,(hl) 
push bc 
Xor a 

Id (POCIT+1),a 
call PRD 

Id a,d 
and1 
Idd,a 

ore 

jp nz,CHYC 
Idd,2 

pop hl 
push de 
call DIVIDE 
Id hl,14848 
push hl 

Id de,257 
call 8866 


pophl 


„Opět snížíme počítadlo 
;a vytiskneme číselník. 


;Ořízneme nepotřebné 
„bajty ze sektoru 


sten si přepočítáme na 
„fyzický a do diskové RAM 


„ho načteme. 

sV potřebné délce 

pop bc ;ho přeneseme 

Id de,(LDADR+1) „tam, kam patří. 

Idir „Nahráno, vypnout motory 
jp 737 sa odstránkovat. Návrat! 


Id a,(15979) 
call 8620 
Id e,(ix+3) 
Id d,0 
Idb,-1 
ora 

inc b 

sbc hl,de 
jr ne,DVO 
add hl,de 
Idc,l 

ret 


push bc 
Id bc,FATKA-512 
Id de,341 
ora 

LESS inc b 
inc b 

sbc hl,de 
jr ne,LESS 
add hl,de 
Ide, 
Idd,h 
sd 

rre 
exaf,af' 
add hl,de 
add hl,bc 
Ide,(hl) 
inc hl 
Idd,(hl) 
dec hl 
exaf,af' 
jr ne,NODD 
Id a,e 
Ide,d 

jr BOTH 
Ida,d 
rrca 

rrca 

rrca 

rrca 

and 15 
Idd,a 
pop bc 


NENITU 
SRS 


PRD 


POCIT 


STO 


NESTO 


DESET 


NEDESET 


CIF1 


CIF2 


CIF3 


FATKA 


ZASOBA 


JMENO 


ZACATEK 
TAB 


END 
LENGHT 


Programování 


ret 


Ida,7 

out (254),a 
deca 

ora 

jp nz, SRS 
Ida,127 

in a,(254) 
rra 

jr c,NENITU 
jp CMUCHEJ 


push hl 
push bc 
push de 
Ida,22 
rst 16 
Id a,20 
rst 16 
Ida,14 
rst 16 
Id a,0 
Id d,100 
Ide,0 
sub d 
jp c,NESTO 
inc e 

jp STO 


add a,d 

Id hl,CIF1+1 
Id (hl),e 
Ide,0 

Id d,10 
sub d 

jp c,NEDESET 
inc e 

jp DESET 


add a,d 

Id hl,CIF2+1 
Id (hl),e 

Id hl,CIF3+1 
Id (hl),a 
Ida,0 

add a,48 
rst 16 
Ida,0 

add a,48 
rst 16 
Ida,0 

add a,48 
rst 16 

pop de 

pop bc 
pophl 

ret 


egu 25000 

egu 23296 

defm „FileName“ 
defb 0,0,“B“ 

egu 25000 

defw 0 

defw $3EF7 


egu END-YEDEME 


„Pokud se námi hledaný 
sfajl odmítl nalézat na 
stomto disku, sršíme 

sa čekáme, až chudák 
„uživatel vymění disk 

sa zmáčkne mezeru. 


„Tisk číselníku je tento: 
„Aby se neměnily registry, 
stak je uložíme. 

„Print AT 20,14 


s(souřadnice si 
„klidně změňte). 


„Oddělíme stovky. 


„Odečti sto. 

„Přehnal jsi to? 

„Ne - jedna 100 k dobru. 
„Zkus další. 


„Stovky naládujem do 
„programu. 

„jdeme na 

„desítky. 

„Odečti deset. 
„Přehnal jsi to? 

„Ne - taky dobrá. 
„Každá desítka se hodí. 


„Teď naládujeme desítky 


+a jednotky, co nám po té 
„machinaci zbyly. 


„A vyplivnem stovky 


„a desítky 


ja jednotky! 


„Tak číselník je, 

steď už jen obnovit si 
„registry 

ja vrátit se v program. 


„Místo v paměti pro FAT 
1(2,5 kB). 

„Místo pro mapu souboru 
(200 B). 

„Jméno fajlu doplněné 
„nulami a příponou. 
„Počáteční adresa fajlu. 
„Tabulka pro přestránko- 
„vání do diskové ROM. 
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Dneska si řekneme, jak to vlastně 
v ROM D40 funguje, hlavně o přechodu ze 
ZX ROM do ROM D40. Jak už všichni víte, 
jsou vstupními body do ROM D40 adresy 0 
a 8. Pokud obsahuje registr PC hodnotu O 
nebo 8, je místo ZX ROM připojena ROM 
D40. Tyto dva vstupní body ale musíme roz- 
lišovat. Adresa O slouží pro speciální opera- 
ce: RESET, SNAP, návrat z rutiny ZX ROM, 
návrat pro tisk chybového hlášení, čtení 
a zápis znaku z/do sekvenčního souboru. 
Adresa 8 je obsazena interpretem BASICUu, 
kdy po zavolání RST 8 ze ZX ROM je pře- 
stránkováno do ROM D40, kde se zpracová- 
vají příkazy pro disketovou jednotku. 


Nejdříve něco o RST 0. Možná vás zara- 
zily ty možnosti, ale je to skutečně tak. Co 
se tedy děje po přestránkování? Nejdříve 
se skutečně uloží stav přerušení v době vo- 
lání skoku na adresu O, uloží se obsahy re- 
gistrů a kontroluje se tabulka na adrese 
H3EEF. Pokud bude narušena, provádí se 
reset počítače. V dalším kroku se kontrolu- 
je obsah adresy +£3EF7, jestli se neprovádí 
návrat z rutiny ZX ROM (£4F) nebo chybo- 
vého hlášení (45). Pokud je zde hodnota 
+4F, jsou obnoveny registry a provede se 
návrat zpět do volajícího programu s tím, 
že zůstane přistránkována ROM D40. Při 
hodnotě 445 jsou obnoveny registry, po- 
tom se provede část programu na adrese 
+145, který je opsán s malými změnami 
ze ZX ROM a provede se buď tisk hlášení 
MDOSu (£18b) a návrat do ZX ROM, nebo 
se přímo vrátíme do ZX ROM, kde se tisk- 
ne hlášení ZX ROM. V obou případech je 
ale původní hodnota přepsána hodnotou 
+20, tedy žádná činnost. Pokud ale není 
žádná z těchto hodnot, začne se kontrolo- 
vat tabulka povolených návratových adres 
(předtím je ještě takový malý pozůstatek 
z ladící rutiny, ale tím se nebudeme zabý- 
vat). 


O co vůbec tímto jde? Když voláme CALL 
O nebo RST 0, je na zásobník uložena ná- 
vratová adresa. My si tuto adresu vyzvedne- 
me a porovnáme ji s povolenými návratový- 
mi adresami. Pokud nebude v tabulce, pro- 
vede se reset. Začátek tabulky je na adrese 
+19A a obsahuje celkem 5 položek. První 
slovo je návratová adresa, druhé slovo je 
adresa programu, kam se bude skákat, po- 
kud návratová adresa souhlasí. Tabulka je 
zakončena slovem 0. Jsou zde adresy pro- 


BA 





gramů pro čtení a zápis znaku z/do sek- 
venčního kanálu a SNAPu. Nyní si asi řek- 
nete, co je to za nesmysl?! 


Tak nejdříve SNAP. Jistě jste si již všimli 
toho tlačítka na konektoru, který je připojen 
na sběrnici. Ano, je to tlačítko SNAP. Nebu- 
du znovu popisovat, co to je SNAP. Důležité 
je, že po jeho stisku se vyvolá NMI. Autor 
článku v ZX Magazínu 38.4/1994 má prav- 
du, že se na adresu *66 vnutí instrukce 
RST 0, která vyvolá skok na adresu 0. Tak- 
že to není nic neobvyklého. Zastavíme se 
u čtení/zápisu znaku z/do sekvenčního ka- 
nálu. Je to velice jednoduché. Pokud se po- 
díváte na struktury kanálových dat, zjistíte, 
že pro každý kanál je vyhrazeno 5 bytů. Prv- 
ní 2 byty je adresa rutiny pro výstup, druhé 
dva pro vstup a poslední je kód jednopís- 
menného názvu kanálu. Nyní ještě zůstává 
rozlišit vstup a výstup do kanálu. 


Je jasné, že se jako adresa nemůže do 
obou uložit O (zkuste přemýšlet proč). Ale 
stačí najít v ZX ROM instrukce RST 0 (v ko- 
mentovaném výpisu ZX ROM je nenajdete, 
ale jsou tam), jeden bude pro vstup, jiný pro 
výstup. Adresy těchto instrukcí si uložíme 
jako vstup a výstup a podle návratových ad- 
res potom rozeznáváme, jakou operaci bu- 
deme požadovat. Ale abych se ještě trochu 
opravil. Kdo už trochu zkoumal práci se 
sekvenčními soubory, tak ví, že se pro ka- 
nál se sekvenčním souborem nevyhrazuje 
pouze 5 bytů, ale více (nechci přijímat dopi- 
sy, ve kterých mě upozorňujete na tuto dez- 
informaci, proto to zde uvádím, na principu 
se ale nic nemění). Přesný popis práce se 
sekvenčními soubory si ale popíšeme jindy 


k adrese O snad ani říci nedá. 


Za zmínku ještě možná stojí popis strán- 
kovací rutiny od pana Svozila, publikované 
v ZX Magazínu 6/1993. J. Flaška to popisu- 
je jako simulaci BASIC příkazu POKE. On 
ten pojem „simulace“ je trochu zavádějící, 
protože to není přímo interpretace příkazu 
POKE, ale výsledek těchto operací je stejný. 
Tento prográmek využívá principu práce 
s proudy (kanálovými, ne mořskými) a prin- 
cipu zápisu znaku do sekvenčního souboru. 


Ale popořádku. Když se provádí výstup 
znaku na kanál, je voláno RST 410. Vyzved- 
ne se adresa začátku kanálových dat pro 


odruhé 


pořádně 


Petr Žabenský 


otevřený kanál, do HL se vyzvedne adresa 
programu výstupu znaku na kanál, je dána 
do HL a do DE je adresa uložení vyššího 
byte adresy pro výstup znaku. V A je znak, 
který se má zapisovat. Nyní se vyvolá pro- 
gram pro výstup znaku. Důležitý je právě 
obsah registru DE a A. Když se podíváte do 
stránkovacího prográmku, všimnete si těch- 
to dvou instrukcí: 


Id a,i4F 
Id de,TAB-++1A 


Hodnota +4F způsobuje návrat s při- 
stránkovanou ZX ROM (zapisovaný znak). 
V DE je ukazatel na začátek hlavičky otevře- 
ného souboru. 


Teď něco nakousnu z kanálových infor- 
maci v ROM D40. Kanálová data pro otevře- 
ný soubor mají velikost 544 bytů, 32 bytů je 
hlavička a 512 bytů je bufer. Hodnoty za ná- 
věštím TAB jsou velice důležité z hlediska 
zápisu hodnoty do bufferu. První slovo je 
počet zapsaných znaků v bufferu (v našem 
případě O) a druhé slovo je adresa v buffe- 
ru, kam se bude daný znak zapisovat (v na- 
šem případě +£3EF7). Protože tyto informa- 
ce jsou uloženy až na konci hlavičky, musí- 
me do DE uložit právě TAB-+1A, kde +1A je 
relativní posun na tyto parametry v hlavič- 
ce. Potom zavoláme **25AB, kde je instruk- 
ce RST 0. Po přestránkování je zjištěno pod- 
le návratové adresy, že se jedná o zápis 
znaku do sekvenčního souboru a je prove- 
den skok na adresu E23. A nyní už výpis 
programu: 


0E23 Id hl,4001A „posun na infor- 
mace o počtu zapsaných znaků a pozici 
v buferu 
0E26 ei „povol preřušení 
add hl,de „nastav ukazatel 
do hlavičky na patřičné informace - nyní 
ukazuje na začátek TAB 
Id e,(hl) 
psaných znaků (nula) 
inc hl 
Id d,(hl) 
inc hl 
ld c,(hl) sa do BC aktuální 
pozici v buferu v našem případě **3EF7 
inc hl 
Id b,(hl) 
Id (bc),a 
H4F na H3EF7 


s„vyzvedni počet za- 


„uložíme hodnotu 


inc de „zvýšíme počítadlo 
zapsaných znaků 

bit 1,d ja testujeme, jestli 
bylo zapsáno 512 znaků 

jr z, +0E12 „pokud ne, skoč 


na uložení DE a BC 


Protože je v DE hodnota 1, je skok prove- 
den a řízení se vrací zpět do volajícího pro- 
gramu. Obsah TAB se tedy změní, proto je 
ho zapotřebí obnovit, což dělají další in- 
strukce v stránkovací rutině. Nyní máme na 
adrese +3EF7 uloženu hodnotu 44F, takže 
můžeme klidně volat RST O0 a máme k dis- 
pozici ROM D40. Nepotřebujeme žádné sys- 
témové proměnné. Velice mazané, ne? 


Nyní se budeme věnovat těm návratům. 
Nejdříve návrat z rutiny ZX ROM. Protože 
ROM D40 používá některé rutiny, které jsou 
již v ZX ROM, bylo zbytečné je do ROM D40 
znovu vkládat. Autoři vymysleli lepší způ- 
sob, a to volání rutin ZX ROM z ROM D40 
s návratem zpět do ROM D40. Volání rutin 
se provádí přes RST 428 a to takto: 


rst +28 
defw adresa rutiny 


A funguje to takto: 


003B | push af „ulož si a příznaky 


Id a,(*3EEE) jvyzvedni informa- 
ci o snapu 

and a ja otestuj, jestli se 
provádí snap (pokud se provádí SNAP, nelze 
volat rutiny ze ZX ROM) 

jp nz,+034A „pokud ano, skoč 
na návrat přes snap 

pop af jobnov A a příznaky 


Nyní vyzvedneme adresu volané rutiny. 


ex (sp),hl „nastav HL na ulo- 
žení adresy rutiny která se bude volat 
Id (*3E66),de | ;schovej si DE 


Id e,(hl) „vezmi adresu rutiny 
inc hl 

Id a,(hl) 

inc hl ;v HL je nyní ná- 


vratová adresa do volajícího programu 


Nastavíme si adresy na zásobník. 


ex (sp),hl ulož si novou ná- 
vratovou adresu zpět na zásobník 

push hl ulož si HL 

Id hl,it3EF7 „do HL adresa ulo- 
žení kódu činnosti 

Id (hl),i4F „nastav činnost 
„volání rutiny ZX ROM“ 

Id hl,i£0000 „do HL dej návra- 


tovou adresu z rutiny ZX ROM do ROM D40 


ex (sp),hl „ulož ji na zásob- 
ník a obnov HL 
push de ulož adresu vola- 


né rutiny na zásobník 
Id de,(*3E66) | ;obnov si DE 

A provedeme rutinu s návratem do ROM D40. 
jp 41700 „skoč na přestrán- 

kování do ZX ROM 





návratová adresa do volajícího programu 
0000 - návratová adresa do ROM D40 
adresa volaného programu v ZX ROM 
(sem ukazuje SP) 

















Jak to tedy funguje? Po JP 4+1700 dojde 
k přestránkování do ZX ROM. Je vyzvednuta 
adresa volané rutiny a proveden skok na 
tuto rutinu. Po ukončení rutiny je vyzvednu- 
ta ze zásobníku hodnota O, dojde k pře- 
stránkování do ROM D40, podle obsahu 
H3EF7 dojde k návratu s přistránkovanou 
ROM D40. Je vyzvednuta návratová adresa 
do volajícího programu, kam se předá řízení 
za DEFW. A to je vše. 


Nejde tedy volat rutiny, které využívají 
ROM D40 (i když šlo by to, ale musely by 
vrátit zpět hodnotu *4F na *3EF7, aby se 
nám nezhroutil systém). A nyní něco o ná- 
vratu pro tisk chybového hlášení. MDOS má 
v sobě zabudovanou kontrolu obsahu adre- 
sy adresované ERR SP. Má zde být uložena 
hodnota +1303 pro návrat po vykonání pří- 
kazu do BASICu. Pokud ale máte zabudova- 
né ošetřování chybových hlášení (ON ER- 
ROR GOTO), musí být zabezepečena i hláše- 
ní ROM D40. Pokud dojde k chybě, skáče 
se na adresu '£2A3. 


02A3 | push bc ulož si adresu ulo- 
žení chyby (při při chybě syntaxe to je návra- 
tová adresa do ZX ROM, při chybě v MDOSu 
to je ERR NR) 

Id hl,+000B „vracet se budeme 
na adresu +000B, aby jsme se nezacyklili 

push hl „uložíme ji na zá- 
sobník 


Nyní otestujeme, jestli se při chybě vrací 
řízení přímo do BASICu na adresu +1303 
nebo byla tato návratová adresa přepsána 
(obsah adresy adesované proměnnou 
ERR SP). Pokud je adresa 1303 a je chy- 
ba MDOSu, tiskne se hlášení na obrazovku 
a řízení se vrací zpět do BASICu. Pokud byla 
tato adresa přepsána a došlo k chybě MDO- 
Su nebo ZX ROM, vrací se řízení na tuto ad- 
resu bez toho, že by se tisklo jakékoliv hlá- 
šení. Je třeba dát pozor, že nedošlo k nulo- 
vání některých důležitých systémových pro- 
měnných MDOSu, které můžou způsobit 
dost závažné problémy (dokonce i chybný 
zápis na disketu). 


Id hl,(£5C3D) | ;adresa položky na 
zásobníku při chybě do HL 

Id e,(hl) „do DE adresa, 
kam se skáče při chybě 

inc hl 

Id a,(hl) 

ex de,hl dej ji do HL 


Nejdříve otestujeme, jestli někdo nepře- 
psal návratovou adresu do BASICu, protože 
používá ošetření chybových hlášení. 


Id bc,£1303 „do BC adresu 
MAIN-4 v ZX ROM 

and a „nuluj CY 

sbc hl,bc „jsou adr. shodné? 


Seriál 
jr nz 4+02C2 ne, skoč na návrat 
do ZX ROM bez tisku chybového hlášení 


ex de,hl „do HL dej adresu 
položky na zásobníku při chybě 


Není přepsána návratová adresa do BA- 
SICu, bude se tedy tisknout chybové hláše- 
ní na obrazovku. 


Id (hl),400 „nuluj obsah adresy 
dec hl 
Id (hl),*00 „po obsloužení 


chyby se řízení vrací na adresu ++0000 


Id hl,ř3EF7 „do HL adresa 
kódu činnosti 
ld (hl),445 sulož kód činnosti 
„výpis chybového hlášení“ 
Návrat do ZX ROM. 
0202 | call 42536 „zastav mechaniky 
Id hl,(£BC5D) © ;do HL adresa zna- 


ku pro dekódování nutné pro návrat do ZX 
ROM 

jp +1700 
kování zpět do ZX ROM 


„skoč na přestrán- 


A teď něco o adrese 8. Jak už jsem na- 
psal, je tato adresa využita interpretem 
BASICu. Někteří lidé ji využívali pro strán- 
kovaní pomocí IM 2, ale to uz je minulost. 
Jak vůbec rozpozná ROM D40, že se jedná 
o její příkaz. Hlavní věc je, že některé pří- 
kazy obsahují znak „*“, některé „£“ 

a některé mají trochu jinou syntaxi, než je 
v ZX ROM (kanály). Všechno se to zase 
děje přes určení návratové adresy, odkud 
bylo voláno RST 8. Tabulka všech návrato- 
vých adresa je na adrese ?5FF. Její struk- 
tura je následující: 


defw adresa příkazu v tabulce syntaxe 
defw odkud bylo voláno RST 8 

defw počet návrat. adres při volání RST 8 
defw adresa progr. vykonávajícího příkaz 


Celá tabulka je opět zakončena 0. 
Jsou tedy postupně vyzvedávány adresy 
příkazů v tabulce syntaxe a porovnávány 
s obsahem adresy +5C74 (T ADDR). Po- 
kud jsou stejné, je vyzvednuta návratová 
adresa při RST 8. Pokud jsou i tyto stejné, 
je vypočtena výška zásobníku při zavolání 
RST 8 (vrchol zásobníku pop RST 8 mínus 
obsah adresy 45C3D (ERR SP)). Když 
jsou i tyto stejné, je proveden skok na 
podprogram. 


Poslední test nám vylučuje například 
použití rozšíření BASICu například progra- 
mem PRO-DOS, který zvyšuje výšku zásob- 
níku o 1 návratovou adresu, čímž je tento 
test negativní u všech příkazů. Prohlížení 
tabulky a porovnávání hodnot zajišťuje 
program na adrese +266. Při zpracovávání 
příkazů se již potom postupuje jako v ZX 
ROM. 


To by bylo pro dnešek asi všechno. u 


(pokračování příště) 
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Seriál 


Pár rutinek MDOSu, které se hodí 


Petr Žabenský 


A je tady další dodatek k mému článku 
o zajímavostech disketové jednotky. Ono 
těch rutinek v ROM D40 je strašně hodně, 
některé nakousl ve své miniknize (to slovo 
se mi strašně líbí) George K. Možná, že jako 
autor komentovaného výpisu, který je už 
snad mezi lidmi, jsem sám proti sobě, ale 
co se dá dělat. Ti, kdo ho ještě namají, ať si 
ho pořídí. Ale tady je několik adres rutin. 


ANALWDNM (i10E2) - analyzuje jméno disku v DNZONE1 
Vstup: jméno disku v DNZONE1 
Výstup: Z, NC není jméno v DNZONE1 
NZ, Cv DNZONE1 je normální jméno 
NZ, NC v DNZONE1 je jako jméno určení mechaniky 
(A,B, C, D),vA je číslo mechaniky (0, 1, 2, 3) po- 
kud je v A 255, bylo chybné jméno disku 


ARRANGNM (3107C) - upraví jméno souboru v FNZONE1 
na masku, převede „*“ 
Vstup: ve FNZONE1 je jméno souboru 
Výstup: ve FNZONE1 je maska 
C bylo použito wildchars 
NZ byla vložena přípona 
Z nebyla vložena přípona 


BWRITE (12296) - slouží pro zápis sektoru na disketu 
Vstup: HL adresa paměti, odkud se bude zapisovat 
B číslo stopy, kam se bude zapisovat 
C číslo sektoru, kam se bude zapisovat 
D počet sektorů, které se budou zapisovat 
E počet opakování při chybě CRC (1-žádné 2-jed- 
no, 3-dvě) 


Tady se na chvíli zastavím. V miniknize 
byla totiž chyba. V E není počet opakování 
při CRC, SEEK etc., jak se tam píše, ale 
pouze při chybě CRC, a není 1=dva pokusy, 
ale žádný pokus. Tady je kousek výpisu: 
23B2 bit 3,d „byla chyba CRC ? 


23B4  jrz,£23B9 jne,skoč na konec 
operace 

23B6 dece „sniž počet opako- 
vání 

23B7 jr nz 2387 „další pokus? ano, 


skoč na opakování operace 


Dále A nemusí obsahovat číslo disku, 
protože se bere obsah adresy +3E6B. Ale 
pokračujme dále. 


BREAD (422A5) - slouží pro načtení sektoru z diskety, pa- 
rametry stejné jako u BWRITE 


BFORMA (£229C) - slouží k naformátování stopy, parame- 
try stejné jako u BWRITE 


CMPDSK (i1CD5) - načte BOOT z disku, jehož číslo je na 

+P3E6B, porovná se jménem v SRAM, pokud je jiné, načte 

nové parametry a jméno diskety v drivu 

Výstup: Z jméno diskety v drivu a jméno v SRAM je stejné 
NZ jména jsou jiná 


DFILER (i1F88) - vymaže soubor z diskety 
Vstup: HL adresa položky adresáře v DIRBUF 


DRWCMP (£21AC) - vypočte adresu parametrů mechaniky 
Vstup: A číslo mechaniky 
Výstup: IX adresa parametrů mechaniky 

Z mechanika není připojena 

NZ mechanika je připojena 


DSKSTP (42536) - zastaví mechaniky 


FINDEMPTYFAT (20F6) - najde první prázdnou položku 
FAT od položky v HL 
Vstup: HL číslo položky FAT, od které se začne hledat 
Výstup: HL číslo položky, která je volná 

Z taková položka existuje 

NZ taková položka neexistuje 


FIRSTEMPTY (12150) - najde první volnou položku adresáře 
Vstup: IX adresa parametrů drivu 
Výstup: A číslo nalezené položky 

HL adresa položky v DIRBUF 

Z taková položka existuje 

NZ taková položka neexistuje 


FIRSTMASK (212B) - najde první položku adresáře, kte- 
rá vyhovuje masce v FNZONE1 
Vstup: maska v FNZONE1 
IX adresa parametrů drivu 
Výstup: HL adresa položky v DIRBUF 
Z byla nalezena 
NZ nebyla nalezena 
A číslo položky v adresáři 


FREECOUNT (i1DC2) - spočítá volné sektory na disketě 
Výstup: BC počet volných sektorů 


FYZLOG (41DE9) - převede fyzickou stopu a sektor na lo- 
gický sektor 
Vstup: IX adresa parametrů drivu 
B číslo stopy 
C číslo sektoru 
Výstup: HL číslo logického sektoru 


GETFAT (i1D04) - vyzvedne obsah položky v HL z tabulky 
FAT 

Vstup: HL číslo položky 

Výstup: DE obsah položky 


GETPAR (t1EA1) - přečte BOOT disku, jehož číslo je na 
+3E6B, nastaví parametry a uloží je do systémových pro- 
měnných, uloží jméno diskety do SRAM 

Vstup: +3E6B číslo drivu 


INITALLDR (i1F49) - nastaví parametry všech připojených 
disků z BOOTŮ disket 


LOADBLOCK (3*19AE) - nahraje do paměti soubor 
Vstup: IX začátek uložení dat 
DE délka dat 
4P3E72 uložení adresy, kde je v DIRBUF uložena 
hlavička souboru 
DNZONE1 jméno disku, odkud se bude nahrávat 


LOAWITHF (:1FAB) - vyhledá soubor se jménem v FNZ0- 
NE1 a nahraje data do paměti 
Vstup: HL počáteční adresa uložení dat 

DE délka dat 

IX adresa parametrů drivu 

FNZONE1 jméno souboru upravené na masku 


LOGFYZ (1DF9) - převede logický sektor na fyzickou sto- 
pu a sektor 
Vstup: HL číslo logického sektoru 
IX daresa parametrů drivu 
Výstup: B stopa 
C sektor 


NEXTEMPTY (3£215E) - najde další volnou položku v adresáři 

Vstup: A číslo položky-1, od které se bude prohledávat 
IX adresa parametrů drivu 

Výstup: stejné jako u FIRSTEMPTY 


NEXTMASK (i212D) - najde další položku adresáře vyho- 

vující masce v FNZONE1 

Vstup: A číslo položky-1, od které se bude prohledávat 
IX adresa parametrů drivu 

Výstup: stejné jako u FIRSTMASK 


RDNOEMPTY (12160) - najde první neprázdnou položku od A 
Vstup: A číslo položky-1, od které se bude prohledávat 

IX adresa parametrů drivu 
Výstup: stejný jako u FIRSTEMPTY 


SAVEFILE (42046) - uloží soubor na disk 
Vstup: HL adresa začátku dat 
DE délka dat 
4P3E78 počáteční adresa uložení dat 
AP3E7A délka BASICu bez proměnných 
FNZONE1 jméno souboru 


SECPERDISK (1DDC) - vypočte počet sektorů na disketě 
Vstup: IX adresa parametrů drivu 
Výstup: HL počet sektorů na disketě 


SETACT (i£1C8F) - nastaví drive podle jména v DNZONE1 
jako drive, se kterým se bude pracovat, pokud toto jméno 
nenajde ve jménech drivů, načte parametry všech připoje- 
ných drivů a zkusí to znovu 
Vstup: DNZONE1 jméno disku 
Výstup: Z takový drive byl nalezen 

NZ takový drive nebyl nalezen 


SETDRV (i£1F16) - nastaví drive, se kterým se bude praco- 
vat, podle jména v DNZONE1 
Vstup: DNZONE1 jméno drivu 
Výstup: Z disk s takovým jménem byl nalezen 
NZ disk s takovým jménem nebyl nalezen 
+3E6B číslo drivu 


TESTMSK (2137) - zjistí, jestli jméno souboru odpovídá 
masce v FNZONE1 
Vstup: FNZONE1 maska souboru 
HL adresa uložení jména souboru 
Výstup: Z vyhovuje masce 
NZ nevyhovuje masce 


WFATIFCH (4£1D9D) - zapíše sektor FAT, který je v FATBUF, 
pokud byl jeho obsah změněn 


WRTOFAT (41D1E) - zapíše do FAT obsah DE do položky v HL 
Vstup: HL číslo položky 
DE co se má zapsat 


WSCADR (£1E65) - zapíše sektor adresáře, který je na- 
čten v DIRBUF 
Vstup: +3E6F stopa a sektor, kam se bude zapisovat 

= 





Protože nám do redakce 
chodí dopisy, že písmo v ZX 
Magazínu je příliš malé, roz- 
hodli jsme se pokusně jednu 
rubriku udělat písmem o ně- 
co větším. Ta rubrika není 
žádná jíná, než všemi oblíbe- 
né Intro. Teď jej již budou 
moci číst i téměř slepí lidé... 


ZX Magazín inmobilní! 

Při jedné ze zahořovacích 
jízd Matsoft nezvládl řízení 
a opřel se svým autem v ser- 
pentýnách předním blatní- 
kem o jednu stranu vozovky. 
Naštěstí si vybral tu, kde byla 
celkem pevná skála, na roz- 
díl od té druhé, kde byl po- 
měrně řídký vzduch a několi- 


XOR 


kametrový sráz... Pro ilustra- 
ci přinášíme několik fotek 
postižené Škodivky - pro lep- 
ší vizuální zážitek hned z ně- 
kolika různých úhlů. 


Driver Reguired! 

Tohle není zvolání nebohé- 
ho majitele Windows XX 
(i když by klidně mohlo být, 
obzvláště, interpretujeme-li 
XX jako NT - No Thanx), ale 
Tritola a Dizzyho, kteří se na 
DoxyCon "99 odmítli plaho- 
čit vlakem či autobusem 
a Dizzy pro účel dopravy na 
DC pořídil nové auto. Jediný 
problém zatím je, že ani Tri- 
tol ani Dizzy nemají řidičský 
průkaz. 








New Cassanova? 

Velmi schopný programá- 
tor a velice úspěšný hardwa- 
rový experimentátor PVL, je- 
hož přezdívku někdo zcela 
nesmyslně interpretoval jako 
„Productivity Very Low“, uči- 
nil zajímavý objev svých dal- 
ších schopností. Jak se ex- 
kluzivně podařilo ZX Magazí- 
nu zjistit, při PVLových RARo- 
vacích aktivitách dívky z ne 
zcela jasných příčin omdléva- 
jí blahem... 


Šijí s Matsoftem všich- 
ni čerti? 

To je otázka, která zajímá 
nejednoho spektristu. Jelikož 
nebylo možno tento ZXM se- 
šít strojově, bude Matsoft 
muset všechny výtisky sešít 
ručně sešívačkou. Možná by 
se mu pár ďábelsky rychlých 
pomocníků hodilo... 


Dementi 

Za dementa byl prohlášen 
DIHALT, neboť se nechal od- 
vést do Green Hell (pro ne- 
znalé - na vojnu). 





